Traffic processing method, distributed microservice communication system, medium, and computing device

CN117834505BActive Publication Date: 2026-09-18HANGZHOU LANGHE TECH
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202311867367.9
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2023-12-29
Publication Date
2026-09-18
Estimated Expiration
2043-12-29

AI Technical Summary

Technical Problem

但对于未接入服务网格的应用容器,其流量数据会随机分发给不同的对应有Sidecar容器的应用容器,无法交由指定的应用容器处理

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN117834505B_ABST
    Figure CN117834505B_ABST
Patent Text Reader

Abstract

Embodiments of the present disclosure provide a traffic processing method, a distributed micro-service communication system, a medium and a computing device, the method applied to a service mesh, comprising: monitoring ingress traffic data; in a case where it is determined that the ingress traffic data is sent by an application container without a corresponding Sidecar container, determining whether a specified field is carried in the ingress traffic data, and forwarding the ingress traffic data according to the specified field when the specified field is carried in the ingress traffic data; and processing the ingress traffic data when the specified field is not carried in the ingress traffic data. The above method determines whether a specified field is carried in the ingress traffic data sent by an application container without a corresponding Sidecar container, and determines forwarding or processing the ingress traffic data according to the determination result, so that the Sidecar container can route and process the traffic flowing into the application container, and the traffic data sent by the application container not connected to the service mesh is processed by the specified application container.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments of this disclosure relate to the field of cloud-native technology, and more specifically, the embodiments of this disclosure relate to a traffic processing method, a distributed microservice communication system, a medium, and a computing device. Background Technology

[0002] This section is intended to provide background or context for the embodiments of this disclosure as set forth in the claims. The description herein is not intended to be a prior art simply because it is included in this section.

[0003] In a microservice architecture, a service mesh is an infrastructure layer used to manage and control communication between microservices in a distributed system. It can provide functions such as flow control, load balancing, and service discovery, thereby improving the performance, reliability, and security of the microservice architecture.

[0004] Currently, mainstream service meshes such as Istio, Linkerd, and AWS App Mesh all use the Sidecar pattern for deployment. In a service mesh using the Sidecar pattern, a companion container, called the Sidecar container, is deployed next to each application container. The application container carries the business logic of each microservice, while the Sidecar container can be used to implement other auxiliary functions that are not related to business logic, such as traffic control, load balancing, and service discovery.

[0005] Sidecar containers can perform rate limiting and authentication / security-related processing on inbound traffic to application containers, and can perform routing, load balancing, and version-based traffic distribution on outbound traffic. However, for application containers not connected to the service mesh, their traffic data will be randomly distributed to different application containers with corresponding sidecar containers, and cannot be handled by a designated application container. Summary of the Invention

[0006] In view of this, this disclosure provides a traffic processing method, a distributed microservice communication system, a medium, and a computing device to address the shortcomings of related technologies.

[0007] In a first aspect of this disclosure, a traffic processing method is provided, applied to a service mesh, the service mesh providing multiple sidecar containers, each sidecar container corresponding to an application container, the method comprising:

[0008] Monitor inbound traffic data;

[0009] If it is determined that the inbound traffic data is sent by an application container that does not have a corresponding Sidecar container, and if it is determined that the inbound traffic data carries a specified field, the inbound traffic data is forwarded according to the specified field; if it is determined that the inbound traffic data does not carry the specified field, the inbound traffic data is processed.

[0010] Optionally, monitoring inbound traffic data may also include:

[0011] If it is determined that the ingress traffic data has been forwarded and the specified field indicates that the ingress traffic data needs to be forwarded to the current application container, the ingress traffic data is processed.

[0012] Optionally, monitoring inbound traffic data may also include:

[0013] Based on whether the inbound traffic data carries a specified identifier, it is determined whether the inbound traffic data is sent by an application container that does not have a corresponding Sidecar container.

[0014] Optionally, if it is determined that the inbound traffic data is sent by an application container that does not have a corresponding Sidecar container, the method further includes:

[0015] The specified identifier is added to the inbound traffic data to determine that the inbound traffic data has been forwarded based on the specified identifier.

[0016] In a second aspect of the present disclosure, a distributed microservice communication system is provided, including a plurality of first application containers that do not correspond to a Sidecar container and a plurality of second application containers that correspond to a Sidecar container.

[0017] The first application container is used to send traffic data to the second application container;

[0018] Any of the second application containers is used to send traffic data to another second application container and to monitor inbound traffic data. It is also used to forward the inbound traffic data according to the specified field when it is determined that the inbound traffic data is sent by the first application container and the inbound traffic data carries a specified field; and to process the inbound traffic data when it is determined that the inbound traffic data does not carry the specified field.

[0019] Optionally, any of the second application containers is further configured to process the ingress traffic data when it is determined that the ingress traffic data has been forwarded and the specified field indicates that the ingress traffic data needs to be forwarded to the current application container.

[0020] Optionally, any of the second application containers is further configured to determine whether the ingress traffic data was sent by the first application container based on whether the ingress traffic data carries a specified identifier.

[0021] Optionally, if it is determined that the ingress traffic data was sent by the first application container, any second application container is further configured to add the specified identifier to the ingress traffic data to determine that the ingress traffic data has been forwarded based on the specified identifier.

[0022] In a third aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect above.

[0023] In a fourth aspect of this disclosure, a computing device is provided, comprising:

[0024] processor;

[0025] Memory used to store processor-executable programs;

[0026] The processor implements the method described in the first aspect above by running the executable program.

[0027] According to the embodiments of this disclosure, when ingress traffic data sent by an application container that does not correspond to a Sidecar container is detected, it is determined whether the ingress traffic data carries a specified field. Based on the determination result, it is determined whether to forward or process the ingress traffic data, so that the Sidecar container can perform routing processing on the traffic flowing into the application container and hand over the traffic data sent by the application container that is not connected to the service mesh to the specified application container for processing. Attached Figure Description

[0028] The above and other objects, features, and advantages of this disclosure will become readily apparent from the following detailed description of exemplary embodiments, taken in conjunction with the accompanying drawings. Several embodiments of this disclosure are illustrated in the drawings by way of example and not limitation, in which:

[0029] Figure 1 A schematic diagram illustrating traffic processing methods in related technologies is provided.

[0030] Figure 2 A flowchart illustrating a traffic processing method according to an embodiment of the present disclosure is shown schematically;

[0031] Figure 3 A schematic diagram illustrating a traffic processing method according to an embodiment of the present disclosure is shown.

[0032] Figure 4A schematic diagram of a distributed microservice communication system according to an embodiment of the present disclosure is shown.

[0033] Figure 5 A schematic diagram of a computer-readable storage medium according to an embodiment of the present disclosure is shown.

[0034] Figure 6 A schematic diagram of a computing device according to an embodiment of the present disclosure is shown.

[0035] In the accompanying drawings, the same or corresponding reference numerals indicate the same or corresponding parts. Detailed Implementation

[0036] The principles and spirit of this disclosure will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are given merely to enable those skilled in the art to better understand and implement this disclosure, and are not intended to limit the scope of this disclosure in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0037] Those skilled in the art will recognize that embodiments of this disclosure can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0038] According to embodiments of this disclosure, a traffic processing method, a distributed microservice communication system, a computer-readable storage medium, and a computing device are proposed.

[0039] In this article, it is important to understand that any number of elements in the accompanying figures is for illustrative purposes and not for limitation, and any naming is for distinction only and has no limiting meaning.

[0040] The principles and spirit of this disclosure will be explained in detail below with reference to several representative embodiments. Invention Overview

[0042] In a microservice architecture, a service mesh is an infrastructure layer used to manage and control communication between microservices in a distributed system. It can provide functions such as flow control, load balancing, and service discovery, thereby improving the performance, reliability, and security of the microservice architecture.

[0043] Currently, mainstream service meshes such as Istio, Linkerd, and AWS App Mesh all use the Sidecar pattern for deployment. In a service mesh using the Sidecar pattern, a companion container, called the Sidecar container, is deployed next to each application container. The application container carries the business logic of each microservice, while the Sidecar container can be used to implement other auxiliary functions that are not related to business logic, such as traffic control, load balancing, and service discovery.

[0044] Sidecar containers can perform rate limiting and authentication / security-related processing on inbound traffic to application containers, and can perform routing, load balancing, and version-based traffic handling on outbound traffic to application containers.

[0045] However, the inventors discovered that for application containers not connected to the service mesh, their traffic data is randomly distributed to different application containers with corresponding Sidecar containers, and cannot be processed by a designated application container. For example... Figure 1 As shown, in client 1, the application container C1, which does not have a corresponding Sidecar container, has its traffic data randomly distributed to application containers P1 and P2, which have corresponding Sidecar containers, in service nodes 1 and 2. In client 2, the application container C2 has a corresponding Sidecar container. The Sidecar container can perform routing processing on the traffic flowing out of the application container, so that its traffic data can be directed to the application container P2.

[0046] Therefore, the inventors conceived of a method to determine whether the inbound traffic data carries a specified field that matches the routing rules. If the specified field is found to be present in the inbound traffic data, the inbound traffic data is forwarded according to the routing rules corresponding to the specified field, and forwarded to the application container corresponding to the target address. If the specified field is not found in the inbound traffic data, it can be determined that the inbound traffic data does not need to be forwarded and is processed by the application container corresponding to the Sidecar container. This allows the Sidecar container to route traffic flowing into the application container and, when receiving traffic data sent by an application container that is not connected to the service mesh, to hand it over to the specified application container for processing.

[0047] After introducing the basic principles of this disclosure, various non-limiting embodiments of this disclosure will be described in detail below.

[0048] Exemplary methods

[0049] The following is for reference. Figure 2 This document describes a traffic processing method according to an exemplary embodiment of the present disclosure.

[0050] Figure 2An illustrated traffic processing method according to an embodiment of the present disclosure is applied to a service mesh, the service mesh providing multiple sidecar containers, each sidecar container corresponding to an application container, the method comprising:

[0051] Step S101: Monitor inbound traffic data;

[0052] Step S102: If it is determined that the ingress traffic data is sent by an application container that does not correspond to a Sidecar container, and if it is determined that the ingress traffic data carries a specified field, the ingress traffic data is forwarded according to the specified field; if it is determined that the ingress traffic data does not carry the specified field, the ingress traffic data is processed.

[0053] In this embodiment, routing rules can be pre-configured in the routing table, and the objects to which the routing rules apply can be specified. The objects to which the routing rules apply can include inbound traffic data and / or outbound traffic data. The routing rules can include the identifier of the traffic data and the destination address. The identifier of the traffic data can refer to a specific field in the request header or a specific request parameter, etc. The specific settings can be made according to the application scenario, and this disclosure does not limit this.

[0054] In this embodiment, the Sidecar container can determine whether the inbound traffic data carries a specified field that matches the routing rules. If the specified field is found to be carried in the inbound traffic data, the inbound traffic data can be forwarded according to the routing rules corresponding to the specified field to the application container corresponding to the target address. If the specified field is not found to be carried in the inbound traffic data, the inbound traffic data can be determined not to be forwarded and can be processed by the application container corresponding to the Sidecar container.

[0055] This embodiment detects inbound traffic data sent by application containers that do not have corresponding Sidecar containers. It determines whether the inbound traffic data carries a specified field and decides whether to forward or process the inbound traffic data based on the determination result. This allows the Sidecar container to route traffic flowing into application containers, handing over traffic data sent by application containers not connected to the service mesh to the specified application container for processing. This eliminates the need to connect application containers without corresponding Sidecar containers to the service mesh, and also eliminates the need for application containers to implement routing functions. This allows application containers to focus on implementing business logic, reduces development costs, and improves the versatility of the service mesh.

[0056] like Figure 3As shown, through the traffic processing method of this embodiment, the traffic data of application container C1 in client 1, which does not have a corresponding Sidecar container, is randomly distributed to application containers P1 and P2 in service nodes 1 and 2, which have corresponding Sidecar containers. The Sidecar container of service node 1 performs routing processing on the traffic data flowing into application container P1, and forwards it to application container P2 according to the specified field carried in the ingress traffic data. Thus, the traffic data of application container C1, which does not have a corresponding Sidecar container, can also achieve the effect of being directed to application container P2. 。

[0057] The inventors further discovered that when ingress traffic data sent by an application container without a corresponding Sidecar is forwarded to a designated application container, the designated application container receives the forwarded traffic data as ingress traffic data. The Sidecar container of the designated application container still needs to determine whether the ingress traffic data carries a specified field that matches the routing rules. If it is determined that the ingress traffic data carries a specified field, it will still forward the ingress traffic data according to the specified field, which may cause the ingress traffic data to be sent to the Sidecar container of the designated application container in a loop, and the ingress traffic data cannot enter the designated application container for processing.

[0058] The inventors realized that when it is determined that the ingress traffic data to be forwarded to the current application container has already been forwarded, it can be determined that the ingress traffic data does not need to be forwarded again and can be directly handed over to the current application container for processing.

[0059] In one embodiment, after monitoring inbound traffic data, the traffic processing method may further include:

[0060] If it is determined that the ingress traffic data has already been forwarded, and a specified field indicates that the ingress traffic data needs to be forwarded to the current application container, then the ingress traffic data is processed.

[0061] In this embodiment, it can be determined whether the inbound traffic data has been forwarded by judging whether the inbound traffic data carries a specified identifier. If the inbound traffic data carries a specified identifier, it can be determined that the inbound traffic data has been forwarded.

[0062] In one embodiment, when the Sidecar container processes traffic flowing into the application container, a specified identifier can be added to the ingress traffic data. The specified identifier may refer to a custom field added to the ingress traffic data request header or request body, and this disclosure does not limit this.

[0063] In one embodiment, it can be determined whether the ingress traffic data is sent by an application container that does not have a corresponding Sidecar container based on whether the ingress traffic data carries a specified identifier.

[0064] In this embodiment, when the Sidecar container processes the traffic flowing out of the application container, a specified identifier can be added to the outgoing traffic data. If the incoming traffic data is sent by the application container with a corresponding Sidecar container, the incoming traffic data of the current application container will carry the specified identifier. If the incoming traffic data does not carry the specified identifier, it can be determined that the incoming traffic data was sent by the application container without a corresponding Sidecar container.

[0065] In one embodiment, if it is determined that the ingress traffic data is sent by an application container that does not correspond to a Sidecar container, a specified identifier can be added to the ingress traffic data to determine that the ingress traffic data has been forwarded based on the specified identifier.

[0066] In this embodiment, upon receiving inbound traffic data, it can first be determined whether the inbound traffic data carries a specified identifier. If it does not carry a specified identifier, it indicates that the inbound traffic data was sent by an application container that does not have a corresponding Sidecar container. In this case, a specified identifier can be added to the inbound traffic data. Then, it can be determined whether the inbound traffic data carries a specified field. If it is determined that the inbound traffic data does not carry a specified field, it can be determined that the inbound traffic data does not need to be forwarded and can be processed by the application container corresponding to the current Sidecar container. If it is determined that the inbound traffic data carries a specified field, the inbound traffic data can be forwarded to the corresponding application container according to the specified field. The Sidecar container that receives the forwarded traffic data determines that the inbound traffic data carries a specified identifier and is inbound traffic data that has already been forwarded. Therefore, it can be determined that the inbound traffic data does not need to be forwarded again and can be directly processed by the current application container.

[0067] This embodiment adds a specified identifier to the ingress traffic data. When the ingress traffic data sent by an application container without a corresponding Sidecar has been forwarded to the specified application container, the Sidecar container of the specified application container can determine through the specified identifier that the ingress traffic data to be forwarded to the current application container has already been forwarded. There is no need to forward the ingress traffic data again, and it can be directly handed over to the current application container for processing. This avoids the problem that the ingress traffic data is repeatedly sent to the Sidecar container of the specified application container, and the ingress traffic data cannot enter the specified application container for processing.

[0068] Exemplary System

[0069] Having described the architecture of exemplary embodiments of this disclosure, the following references are made... Figure 4 To describe a distributed microservice communication system according to an exemplary embodiment of the present disclosure.。 Figure 4 A schematic diagram of a distributed microservice communication system according to an embodiment of the present disclosure is shown.

[0070] This includes several first application containers 11 that do not correspond to a Sidecar container and several second application containers 12 that correspond to a Sidecar container;

[0071] The first application container 11 is used to send traffic data to the second application container 12;

[0072] Any second application container 12 is used to send traffic data to another second application container 12 and monitor inbound traffic data. It is also used to forward the inbound traffic data according to the specified field when it is determined that the inbound traffic data is sent by the first application container 11 and the inbound traffic data carries the specified field; and to process the inbound traffic data when it is determined that the inbound traffic data does not carry the specified field.

[0073] This embodiment allows a second application container with a corresponding Sidecar container to detect inbound traffic data sent by a first application container without a corresponding Sidecar container. The container determines whether the inbound traffic data carries a specified field and, based on the determination, decides whether to forward or process the inbound traffic data. This enables the Sidecar container of the second application container to route traffic flowing into it, passing the traffic data sent by the first application container to the designated second application container for processing. This eliminates the need to connect the first application container (which does not have a corresponding Sidecar container) to the service mesh, and also eliminates the need for the first application container to implement routing functions. This allows application containers to focus on implementing business logic, reducing development costs and improving the versatility of the service mesh.

[0074] In one embodiment, any second application container 12 is further configured to process the ingress traffic data when it is determined that the ingress traffic data has been forwarded and a specified field indicates that the ingress traffic data needs to be forwarded to the current application container.

[0075] In this embodiment, it can be determined whether the inbound traffic data has been forwarded by judging whether the inbound traffic data carries a specified identifier. If the inbound traffic data carries a specified identifier, it can be determined that the inbound traffic data has been forwarded.

[0076] In one embodiment, when the Sidecar container processes traffic flowing into the application container, a specified identifier can be added to the ingress traffic data. The specified identifier may refer to a custom field added to the ingress traffic data request header or request body, and this disclosure does not limit this.

[0077] In one embodiment, any second application container 12 is further configured to determine whether the ingress traffic data was sent by the first application container 11 based on whether the ingress traffic data carries a specified identifier.

[0078] In this embodiment, when the Sidecar container processes the traffic flowing out of the application container, a specified identifier can be added to the outgoing traffic data. If the incoming traffic data is sent by the second application container, the incoming traffic data of the current second application container will carry the specified identifier. If the incoming traffic data does not carry the specified identifier, it can be determined that the incoming traffic data was sent by the first application container.

[0079] In one embodiment, if it is determined that the ingress traffic data was sent by the first application container 11, any second application container 12 is further configured to add a specified identifier to the ingress traffic data to determine that the ingress traffic data has been forwarded based on the specified identifier.

[0080] This embodiment adds a specified identifier to the ingress traffic data. When the ingress traffic data sent by the first application container without a corresponding Sidecar container has been forwarded to the specified second application container with a corresponding Sidecar container, the Sidecar container of the specified second application container can determine through the specified identifier that the ingress traffic data to be forwarded to the current second application container has already been forwarded. There is no need to forward the ingress traffic data again, and it can be directly handed over to the current second application container for processing. This avoids the problem that the ingress traffic data is repeatedly sent to the Sidecar container of the specified second application container, and the ingress traffic data cannot enter the specified second application container for processing.

[0081] Exemplary media

[0082] Having described the system of exemplary embodiments of this disclosure, the following references are made. Figure 5 The computer-readable storage medium described herein is used to describe exemplary embodiments of the present disclosure.

[0083] In this exemplary embodiment, the above method can be implemented by a program product, such as a portable compact disc read-only memory (CD-ROM) containing program code, which can run on a device, such as a personal computer. However, the program product disclosed herein is not limited thereto. In this document, a readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0084] This program product can be produced using any combination of one or more readable media. The readable media can be a readable signal medium or a readable storage medium.

[0085] A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0086] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0087] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RE, etc., or any suitable combination thereof.

[0088] Program code for performing the operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0089] Exemplary computing device

[0090] Having described the methods, systems, and media of exemplary embodiments of this disclosure, the following references are made... Figure 6 To describe the computing device of the exemplary embodiments of this disclosure.

[0091] Figure 6 The computing device 60 shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0092] like Figure 6As shown, the computing device 60 is presented in the form of a general-purpose computing device. The components of the computing device 60 may include, but are not limited to: at least one processing unit 601, at least one storage unit 602, and a bus 603 connecting different system components (including the processing unit 601 and the storage unit 602).

[0093] Bus 603 includes a data bus, a control bus, and an address bus.

[0094] Storage unit 602 may include readable media in the form of volatile memory, such as random access memory (RAM) 6021 and / or cache memory 6022, and may further include readable media in the form of non-volatile memory, such as read-only memory (ROM) 6023.

[0095] Storage unit 602 may also include a program / utility 6025 having a set (at least one) of program modules 6024, such program modules 6024 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0096] The computing device 60 can also communicate with one or more external devices 604 (such as a keyboard, pointing device, etc.).

[0097] This communication can be performed via input / output (I / O) interface 605. Furthermore, computing device 60 can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapter 606. Figure 6 As shown, network adapter 606 communicates with other modules of computing device 60 via bus 603. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with computing device 60, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0098] It should be noted that although several units / modules or sub-units / modules of a distributed microservice communication system have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this disclosure, the features and functions of two or more units / modules described above can be embodied in a single unit / module. Conversely, the features and functions of a single unit / module described above can be further divided and embodied by multiple units / modules.

[0099] Furthermore, although the operations of the methods disclosed herein are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0100] While the spirit and principles of this disclosure have been described with reference to several specific embodiments, it should be understood that this disclosure is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for convenience of expression. This disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

Claims

1. A flow processing method, characterized in that, Applied to a service mesh, wherein the service mesh provides multiple sidecar containers, and one sidecar container corresponds to one application container, the method includes: Monitor inbound traffic data; In the case where it is determined that the inbound traffic data is sent by an application container that does not have a corresponding Sidecar container: If it is determined that the inbound traffic data has not been forwarded and the inbound traffic data carries a specified field, the inbound traffic data will be forwarded according to the specified field; if it is determined that the inbound traffic data has not been forwarded and the inbound traffic data does not carry a specified field, the inbound traffic data will be processed. If it is determined that the ingress traffic data has already been forwarded, and the specified field indicates that the ingress traffic data needs to be forwarded to the current application container, then the ingress traffic data is processed.

2. The method according to claim 1, characterized in that, Monitoring inbound traffic data also includes: Based on whether the inbound traffic data carries a specified identifier, it is determined whether the inbound traffic data is sent by an application container that does not have a corresponding Sidecar container.

3. The method according to claim 2, characterized in that, If the ingress traffic data is determined to be sent by an application container that does not have a corresponding Sidecar container, the method further includes: The specified identifier is added to the inbound traffic data to determine that the inbound traffic data has been forwarded based on the specified identifier.

4. A distributed microservice communication system, characterized in that, This includes several first application containers that do not correspond to a Sidecar container and several second application containers that correspond to a Sidecar container; The first application container is used to send traffic data to the second application container; Any of the second application containers is used to send traffic data to another second application container and to monitor inbound traffic data. It is also used to forward the inbound traffic data according to the specified field if it is determined that the inbound traffic data was sent by the first application container and if it is determined that the inbound traffic data has not been forwarded and the inbound traffic data carries a specified field. If it is determined that the inbound traffic data has not been forwarded and the inbound traffic data does not carry the specified field, the inbound traffic data shall be processed. If it is determined that the ingress traffic data has already been forwarded, and the specified field indicates that the ingress traffic data needs to be forwarded to the current application container, then the ingress traffic data is processed.

5. The system according to claim 4, characterized in that, Any of the second application containers is further configured to determine whether the ingress traffic data was sent by the first application container based on whether the ingress traffic data carries a specified identifier.

6. The system according to claim 5, characterized in that, If it is determined that the ingress traffic data was sent by the first application container, any second application container is further configured to add the specified identifier to the ingress traffic data to determine that the ingress traffic data has been forwarded based on the specified identifier.

7. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed by a processor, implements the method of any one of claims 1-3.

8. A computing device, characterized in that, include: processor; Memory used to store processor-executable programs; The processor implements the method of any one of claims 1-3 by running the executable program.

Citation Information

Patent Citations

  • Flow control method and system based on service grid, equipment and medium

    CN113765816A

  • Deployment method and device of single-core operating system in server-free framework based on edge-removed vehicle

    CN117176568A