Data processing method, data transmission method, communication device and storage medium

Abstract

Embodiments of the present application provide a data processing method, a data transmission method, a communication device and a storage medium. The data processing method comprises: when a microservice data packet carrying an identifier is obtained, on the basis of the identifier, determining microservice semantic information of the microservice data packet; on the basis of the microservice semantic information and a microservice processing policy, determining a kernel data packet processing path of the microservice data packet; and on the basis of the kernel data packet processing path, transmitting the microservice data packet to a forwarding egress port.

Description

Data processing method, data transmission method, communication device and storage medium

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on the Chinese patent application with application number 2023107821520 and application date of June 28, 2023, and claims the priority of the Chinese patent application. The entire content of the Chinese patent application is hereby introduced into this application as a reference. Technical Field

[0003] The embodiments of the present application relate to the field of data processing technology, and in particular to a data processing method, a data transmission method, a communication device, and a storage medium. Background Art

[0004] In the current mainstream microservice architecture, the invocation of microservice data packets occurs at the API (Application Programming Interface) gateway of the central cloud or data center. However, for cross-data center communication scenarios or edge computing scenarios, the above microservice architecture will result in longer end-to-end latency and cannot meet the differentiated processing path requirements of different microservice data packets. Therefore, how to shorten the end-to-end latency of microservice data packets and meet the differentiated processing path requirements of different microservice data packets has become a technical problem that needs to be solved urgently.

[0005] Summary of the Invention

[0006] The embodiments of the present application provide a data processing method, a data transmission method, a communication device, and a storage medium, which can shorten the end-to-end delay of microservice data packets and meet the differentiated processing path requirements of different microservice data packets.

[0007] In a first aspect, an embodiment of the present application provides a data processing method, comprising:

[0008] When a microservice data packet carrying an identifier is obtained, determining microservice semantic information of the microservice data packet according to the identifier;

[0009] Determine a kernel data packet processing path for the microservice data packet according to the microservice semantic information and the microservice processing strategy;

[0010] The microservice data packet is transmitted to the forwarding exit according to the kernel data packet processing path.

[0011] In a second aspect, an embodiment of the present application further provides a data transmission method, including:

[0012] Using the data processing method as described in the first aspect, the microservice data packet carrying the identifier is transmitted to the forwarding exit, and the microservice data packet is sent to the second network node through the forwarding exit, so that the second network node forwards the microservice data packet according to the identifier.

[0013] In a third aspect, an embodiment of the present application further provides a data transmission method, including:

[0014] Receive microservice data packets carrying identifiers;

[0015] Using the data processing method as described in the first aspect, the microservice data packet is transmitted to a forwarding exit, and the microservice data packet is sent to a third network node through the forwarding exit, so that the third network node processes the microservice data packet according to the identifier.

[0016] In a fourth aspect, an embodiment of the present application further provides a communication device, comprising: a memory, a processor, and a computer program stored in the memory and runnable on the processor, characterized in that when the processor executes the computer program, it implements the data processing method as described in the first aspect, or the data transmission method as described in the second and third aspects.

[0017] In a fifth aspect, an embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to execute the data processing method as described in the first aspect, or the data transmission method as described in the second and third aspects.

[0018] According to the data processing method, data transmission method, communication device and storage medium provided by the embodiments of the present application, the data processing method of one embodiment includes: when a microservice data packet carrying an identifier is obtained, the microservice semantic information of the microservice data packet is determined according to the identifier, the kernel data packet processing path of the microservice data packet is determined according to the microservice semantic information and the microservice processing strategy, and the microservice data packet is transmitted to the forwarding exit according to the kernel data packet processing path. The data transmission method of another embodiment includes: using the data processing method as described above to transmit the microservice data packet carrying the identifier to the forwarding exit, and sending the microservice data packet to the second network node through the forwarding exit, so that the second network node forwards the microservice data packet according to the identifier. The data transmission method of another embodiment includes: receiving a microservice data packet carrying an identifier, using the data processing method as described above to transmit the microservice data packet to the forwarding exit, and sending the microservice data packet to the third network node through the forwarding exit, so that the third network node processes the microservice data packet according to the identifier. In the above embodiment, when a microservice data packet carrying an identifier is obtained, the microservice semantic information of the microservice data packet can be obtained through the identifier, and the optimal kernel data packet processing path of the microservice data packet is selected in combination with the microservice semantic information and the microservice processing strategy, and the microservice data packet is transmitted to the forwarding exit through the kernel data packet processing path. Since different microservice data packets will be transmitted to the forwarding exit through different optimal kernel data packet processing paths, the embodiment of the present application can shorten the end-to-end delay of the microservice data packet and meet the differentiated processing path requirements of different microservice data packets. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] FIG1 is a schematic diagram of direct communication between a user terminal and a microservice in the related art;

[0020] FIG2 is a schematic diagram of a user terminal communicating with a microservice using an API gateway in related art;

[0021] FIG3 is a schematic diagram of an existing packet sending and receiving path;

[0022] Figure 4 is a schematic diagram of the packet sending and receiving path using eBPF technology;

[0023] FIG5 is a schematic diagram of the packet sending and receiving path when the destination node is a service node on another host;

[0024] FIG6 is a flow chart of a data processing method provided by one embodiment of the present application;

[0025] FIG7A is a schematic diagram of a microservice data packet transmission route in a case where a microservice data packet is generated by a user terminal, provided by one embodiment of the present application;

[0026] FIG7B is a schematic diagram of a microservice data packet transmission route in a case where a network node generates a microservice data packet, provided by one embodiment of the present application;

[0027] FIG7C is a schematic diagram of an orchestrator deployment structure in which a microservice cloud server node is deployed in a multiple DC scenario according to an embodiment of the present application;

[0028] FIG8 is a schematic diagram of the structure of a microservice cloud server registering an application with an orchestrator according to an embodiment of the present application;

[0029] 9 is a schematic diagram of the interaction between modules within the orchestrator after a user terminal starts an application according to an embodiment of the present application;

[0030] FIG10 is a schematic diagram of an orchestrator returning a microservice identifier and configuring a router according to an embodiment of the present application;

[0031] FIG11 is a flowchart of a data transmission method provided by one embodiment of the present application;

[0032] FIG12 is a flowchart of step S302 in FIG11 according to an embodiment of the present application;

[0033] FIG13A is a schematic diagram of a microservice cloud server node deployed in a DC scenario according to an embodiment of the present application;

[0034] FIG13B is a schematic diagram of a microservice cloud server node deployed in a multiple DC scenario according to an embodiment of the present application;

[0035] FIG13C is a schematic diagram of a microservice cloud server node deployed under an edge DC according to an embodiment of the present application;

[0036] FIG14 is a schematic diagram of a communication device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0038] It should be noted that although the device schematics illustrate functional module divisions and the flowcharts illustrate logical sequences, in certain circumstances, the steps shown or described may be performed in a sequence that differs from the module divisions in the device or the sequence in the flowcharts. The terms "first," "second," and so on, used in the specification, claims, and accompanying drawings are used to distinguish similar items and are not necessarily intended to describe a specific sequence or precedence.

[0039] In the embodiments of the present application, words such as "further," "exemplarily," or "optionally" are used to indicate examples, illustrations, or descriptions and should not be interpreted as being more preferred or advantageous over other embodiments or designs. The use of words such as "further," "exemplarily," or "optionally" is intended to present related concepts in a concrete manner.

[0040] In order to more conveniently describe the working principle of the embodiments of the present application later, an introduction to the relevant technical scenarios is given below.

[0041] Traditional developers typically consider an application as an indivisible monolith. However, as application functionality grows in complexity, this development model exponentially increases the difficulty of operating and maintaining the application. To address this issue, developers are beginning to break applications into logically independent functional modules and develop each module separately. These modules are called "microservices." Traditional monolithic applications are typically deployed and run on a single server in the cloud. In a microservices architecture, each microservice module can be processed by servers deployed in different cloud locations. This allows the functionality of a monolithic application to be implemented by running microservices sequentially and enabling inter-service communication. Given that the input parameters of one microservice may be the results of other microservices, the inter-service call relationships and completion sequence significantly impact the overall application functionality. Furthermore, different microservices have varying requirements for network and computing resources. Providing differentiated data packet transmission for different microservices is crucial to ensuring a positive user experience.

[0042] Currently, there are two ways to go from application --> determining the application's microservice composition --> running microservices: direct user completion and API gateway proxy completion. In the user-direct method, the microservice composition of each application, the inter-calling relationships between them, and the server address running each microservice need to be pre-configured on the terminal side. When the application starts, the terminal directly sends a data packet requesting service to the cloud microservice server. In the API gateway proxy method, the application needs to be pre-registered with the API gateway, declaring the application's microservice composition and inter-calling relationships, and saving the server address running each microservice. When the application starts, the terminal sends a service request to an API gateway. The API gateway first determines the application's microservice composition based on the reserved information and then sends a data packet requesting service based on the inter-calling relationships between the microservices.

[0043] The advantage of the user-direct completion method is that users can set different parameters based on the characteristics of different microservices, allowing the network to transmit data packets differently based on these parameters. However, the disadvantage is that application development is not transparent to users. Whenever the composition of the application's microservices or the mutual calling relationships change, users need to update the configuration. In addition, when the number of microservices that make up the application is large or the mutual calling relationships between microservices are complex, the terminal needs to frequently transmit data packets with the cloud server, resulting in increased end-to-end latency. In contrast, the advantage of the API gateway proxy method is that it can make application development completely transparent to users and avoid frequent data packet transmission between the terminal and the cloud server. However, the disadvantage is that the network cannot provide fine-grained services at the microservice level. In addition, the API gateway needs to parse the application's service request data packets at layer 7 of the protocol stack and issue new microservice data packets. In multi-cloud communication scenarios and edge computing scenarios, data packets crossing the seven-layer protocol stack multiple times will cause large end-to-end latency.

[0044] With the emergence of new applications such as XR (Extended Reality) and the Metaverse, users have an increasingly strong demand for high-quality viewing and experience within the constraints of limited computing power and network resources. In order to provide a high-quality experience to scattered users, future data centers or central cloud scenarios will evolve towards multi-cloud communication scenarios and edge computing scenarios. How to implement microservices that are not perceived by users (or terminals) in these scenarios has become a problem that must be solved. Currently, there is no clear solution in the industry. To remedy the above shortcomings, it is necessary to design a simple, feasible, and user-transparent application microservice decomposition, orchestration, and differentiated transmission solution based on comprehensive consideration of computing power resources and network resources. The location of the application microservice composition will be moved from the cloud API gateway to the network or even the terminal, meeting the fine-grained SLA (Service Level Agreement) requirements from end to network to cloud.

[0045] Terminals can directly send requests to microservices, as shown in Figure 1. This direct communication model can meet the needs of small microservice-based applications, but it presents many challenges for large microservice-based applications. Four of these challenges are listed below:

[0046] 1) For applications running on the client, a single page may need to call multiple services multiple times, resulting in multiple network round trips between the terminal and the server, which significantly increases the end-to-end latency.

[0047] 2) Terminal applications are coupled with microservices. When microservices evolve or are refactored, terminal applications need to be modified accordingly, resulting in frequent updates and increased development and maintenance difficulties.

[0048] 3) Microservices are exposed and more vulnerable to attacks, resulting in reduced security;

[0049] 4) Each publicly released microservice must deal with issues such as authorization and SSL (Secure Sockets Layer), which increases the complexity of the process.

[0050] To address these issues, an API gateway can be introduced as the sole entry point for microservices, as shown in Figure 2. This diagram illustrates how a terminal uses an API gateway to communicate with microservices. In addition to routing all microservice requests from the terminal to the server, the API gateway can also provide other functions such as request aggregation, authentication, service discovery, rate limiting, load balancing, SSL termination, and caching.

[0051] eBPF (extended Berkeley Packet Filter) is a kernel technology that allows developers to run specific functions without modifying the kernel code. Specifically, eBPF allows regular user-space applications to package the logic to be executed in the Linux kernel into bytecodes. When certain events (called hooks, which can be system calls or network events, etc.) occur, the kernel will dynamically load and execute the compiled code. Using eBPF technology, data packet redirection and flow control can be implemented in the kernel, greatly shortening the data packet processing path and latency, as shown in Figures 3 to 5 below. Figure 3 is a schematic diagram of the existing packet sending and receiving path. It can be seen that the packet sending and receiving path needs to be from ① to Transmitted sequentially. Figure 4 shows a schematic diagram of the packet sending and receiving path using eBPF technology. When a packet is transmitted to a TC ingress, it can jump directly from TC ingress to TC egress. That is, the nodes between TC ingress and TC egress can be skipped, thereby implementing packet redirection and flow control in the kernel, significantly shortening the packet processing path and latency. Figure 5 shows a schematic diagram of the packet sending and receiving path when the destination node is a service node on another host.

[0052] In the current mainstream microservices architecture, microservice data packets are invoked through an API gateway in a central cloud or data center. However, in cross-data center communication scenarios or edge computing scenarios, this microservices architecture results in long end-to-end latency and fails to meet the differentiated processing paths required for different microservice data packets. Therefore, how to shorten the end-to-end latency of microservice data packets and meet the differentiated processing paths required for different microservice data packets has become a pressing technical challenge.

[0053] Based on this, the present application provides a data processing method, a data transmission method, a communication device and a storage medium. The data processing method of one embodiment includes: when a microservice data packet carrying an identifier is obtained, the microservice semantic information of the microservice data packet is determined according to the identifier, the kernel data packet processing path of the microservice data packet is determined according to the microservice semantic information and the microservice processing strategy, and the microservice data packet is transmitted to the forwarding exit according to the kernel data packet processing path. The data transmission method of another embodiment includes: using the data processing method as described above to transmit the microservice data packet carrying the identifier to the forwarding exit, and sending the microservice data packet to the second network node through the forwarding exit, so that the second network node forwards the microservice data packet according to the identifier. The data transmission method of another embodiment includes: receiving a microservice data packet carrying an identifier, using the data processing method as described above to transmit the microservice data packet to the forwarding exit, and sending the microservice data packet to the third network node through the forwarding exit, so that the third network node processes the microservice data packet according to the identifier. In the above embodiment, when a microservice data packet carrying an identifier is obtained, the microservice semantic information of the microservice data packet can be obtained through the identifier, and the optimal kernel data packet processing path of the microservice data packet is selected in combination with the microservice semantic information and the microservice processing strategy, and the microservice data packet is transmitted to the forwarding exit through the kernel data packet processing path. Since different microservice data packets will be transmitted to the forwarding exit through different optimal kernel data packet processing paths, the embodiment of the present application can shorten the end-to-end delay of the microservice data packet and meet the differentiated processing path requirements of different microservice data packets.

[0054] The embodiments of the present application are further described below with reference to the accompanying drawings.

[0055] As shown in FIG6 , FIG6 is a flowchart of a data processing method provided by an embodiment of the present application. The data processing method may include but is not limited to steps S101 to S103 .

[0056] Step S101: when a microservice data packet carrying an identifier is obtained, microservice semantic information of the microservice data packet is determined according to the identifier;

[0057] Step S102: determining a kernel data packet processing path of the microservice data packet according to the microservice semantic information and the microservice processing strategy;

[0058] Step S103: Transmit the microservice data packet to the forwarding egress according to the kernel data packet processing path.

[0059] In this step, when a microservice data packet carrying an identifier is obtained, the microservice semantic information of the microservice data packet can be obtained through the identifier, and the optimal kernel data packet processing path of the microservice data packet is selected in combination with the microservice semantic information and the microservice processing strategy, and the microservice data packet is transmitted to the forwarding exit through the kernel data packet processing path. Since different microservice data packets will be transmitted to the forwarding exit through different optimal kernel data packet processing paths, the end-to-end delay of the microservice data packet can be shortened, and the differentiated processing path requirements of different microservice data packets can be met.

[0060] In one embodiment, this data processing method can be applied to user terminals or network nodes. By moving the generation of microservice data packets for a given application from the cloud API gateway to the network node and user terminal, and carrying identifiers in the generated microservice data packets, differentiated transmission of microservice data packets in scenarios such as cross-DC communication and edge computing can be achieved, thereby meeting the fine-grained SLA requirements of the application.

[0061] In one embodiment, the data processing method can be applied to a user terminal. Taking the application of the data processing method to a user terminal as an example, after the user terminal receives one or more identifiers generated by the control unit, one or more microservice data packets carrying the identifiers will be generated accordingly, thereby obtaining a microservice data packet carrying the identifier. The microservice semantic information of the microservice data packet can be obtained through the identifier. The optimal kernel data packet processing path for the microservice data packet is selected in combination with the microservice semantic information and the microservice processing strategy. The microservice data packet is transmitted to a forwarding exit through the kernel data packet processing path, and the forwarding exit is connected to the first network node. Since different microservice data packets are transmitted to the forwarding exit through different optimal kernel data packet processing paths, the end-to-end delay of the microservice data packet can be shortened, and the differentiated processing path requirements of different microservice data packets can be met.

[0062] In one embodiment, the data processing method can be applied to a network node. Taking the application of the data processing method to a first network node as an example, the first network node is the first network node connected to a user terminal. After the user terminal sends a microservice data packet carrying an identifier to the first network node, the first network node receives the microservice data packet carrying the identifier. The first network node obtains the microservice data packet carrying the identifier through the identifier and, based on the microservice semantic information and the microservice processing strategy, selects the optimal kernel data packet processing path for the microservice data packet. The microservice data packet is transmitted to a forwarding egress via the kernel data packet processing path, and the forwarding egress is connected to a second network node. Because different microservice data packets are transmitted to the forwarding egress via different optimal kernel data packet processing paths, the end-to-end latency of the microservice data packet can be shortened, and the differentiated processing path requirements of different microservice data packets can be met.

[0063] In one embodiment, during transmission along the kernel packet processing path, microservice packets sequentially pass through the transport layer, network layer, and physical layer, enabling the protocol stack layer for processing microservice packets to be lowered from the API gateway's seven layers to three. It should be noted that during transmission along the kernel packet processing path, microservice packets pass through at least the transport layer, network layer, and physical layer, but are not limited to these three layers.

[0064] In one embodiment, as shown in FIG7A , after the user terminal receives the three identifiers ID A, ID B, and ID C generated by the control unit, it generates a first microservice data packet carrying the identifier ID A (the triangle shown in the figure), a second microservice data packet carrying the identifier ID B (the diamond shown in the figure), and a third microservice data packet carrying the identifier ID C (the five-pointed star shown in the figure). During the transmission of the first microservice data packet, the second microservice data packet, and the third microservice data packet along the kernel data packet processing path, they pass through the transport layer, the network layer, and the physical layer in sequence and are transmitted to the forwarding exit. The forwarding exit is connected to the first network node, which is the first network node connected to the user terminal. It should be noted that the control unit can determine the microservice processing strategy for each microservice data packet based on the current network resource status and computing power resource status. For example, as shown in the table in Figure 7A, the best routing policy corresponding to identifier ID A is policy a, the target address corresponding to policy a is the cloud gateway GWA, and the next hop is router E; the best routing policy corresponding to identifier ID B is policy b, the target address corresponding to policy b is the cloud gateway GWA, and the next hop is router E; the best routing policy corresponding to identifier ID C is policy c, the target address corresponding to policy c is the cloud gateway GWB, and the next hop is router F.

[0065] In one embodiment, as shown in FIG7B , a user terminal sends an application service request packet to a first network node, which is the first network node connected to the user terminal. The first network node generates microservice packets carrying identifiers based on the application service request packet. The microservice packets include a first microservice packet carrying identifier ID A (a triangle in the figure), a second microservice packet carrying identifier ID B (a diamond in the figure), and a third microservice packet carrying identifier ID C (a five-pointed star in the figure). Identifiers ID A, ID B, and ID C are generated by a control unit based on the application service request packet forwarded by the first network node. During transmission along the kernel packet processing path, the first, second, and third microservice packets sequentially pass through the transport layer, network layer, and physical layer before being transmitted to a forwarding egress. The forwarding egress is connected to a second network node, which is another network node connected to the first network node. It should be noted that the control unit can determine the microservice processing strategy for each microservice packet based on the current network resource status and computing resource status. For example, as shown in the table in Figure 7B, the best routing policy corresponding to identifier ID A is policy a, the target address corresponding to policy a is the cloud gateway GWA, and the next hop is router E; the best routing policy corresponding to identifier ID B is policy b, the target address corresponding to policy b is the cloud gateway GWA, and the next hop is router E; the best routing policy corresponding to identifier ID C is policy c, the target address corresponding to policy c is the cloud gateway GWB, and the next hop is router F.

[0066] In one embodiment, the identifier is obtained from the control unit, and the identifier carries the microservice semantic information. The control unit is deployed in the network. It should be noted that the control unit includes but is not limited to an orchestrator. Taking the control unit as an orchestrator as an example, as shown in FIG7C , an orchestrator is deployed in the network. The orchestrator may include a readable domain name and address mapping module, an application sub-function logical semantic management module, a microservice registration module, and a routing decision module, which are used to respectively implement functions such as application readable domain name and address mapping, application sub-function logical semantic management, microservice registration, and routing decision. The orchestrator regularly maintains the link between it and the routers in the network. For example, the orchestrator regularly broadcasts its IP address to the routers.

[0067] In one embodiment, as shown in Figure 8, assuming the control unit is an orchestrator, when creating a new application, the application developer registers the application with the orchestrator and declares the application's microservice composition, the inter-microservice call relationships, and the IP address of the server that handles each microservice. Within the orchestrator, the microservice registration module records the application's microservice composition and inter-microservice call relationships, while the readable domain name and address mapping module records the server's IP address.

[0068] In one embodiment, as shown in Figure 9, taking the orchestrator as the control unit, when a user terminal launches an application, it sends an application service request to the orchestrator. Within the orchestrator, the readable domain name and address mapping module receives the application service request and notifies the application sub-function logical semantic management module to process it. The application sub-function logical semantic management module accesses the microservice registration module to obtain the application's microservice components and information about inter-microservice calls. Based on this information, it generates one or more microservice requests. The application sub-function logical semantic management module then sends the microservice request to the readable domain name and address mapping module and the routing decision module, respectively.

[0069] In one embodiment, when a microservice request returns to the routing decision module, the optimal routing strategy is determined based on the current network resource status and computing power resource status. When a microservice request returns to the application-readable domain name and address mapping module, an identifier in the target address format is generated, which carries the semantic information of the microservice.

[0070] In one embodiment, as shown in FIG10 , the orchestrator configures routers in the network according to all generated routing policies, and returns all generated identifiers as target addresses to the user terminal.

[0071] In one embodiment, the microservice processing strategy can be obtained by the control unit based on the current network resource status and computing resource status, or can be pre-configured by the control unit.

[0072] In one embodiment, when a microservice data packet is a microservice data packet that is sensitive to latency, the microservice processing strategy includes: in the kernel, using an extended Berkeley Packet Filter to redirect and control the flow of the microservice data packet. eBPF (extended Berkeley Packet Filter) is a kernel technology that allows developers to run specific functions without modifying the kernel code. Specifically, eBPF allows regular user-space applications to package the logic to be executed in the Linux kernel into bytecode, and when certain events (called hooks, which can be system calls or network events, etc.) occur, the kernel will dynamically load and execute the compiled code. Using eBPF technology, data packet redirection and flow control can be implemented in the kernel, greatly shortening the processing path and latency of the data packet. In some examples, for microservice data packets that are sensitive to latency, eBPF technology can be used to enable microservice data packets to be processed directly in the kernel, avoiding switching between user mode and kernel mode.

[0073] In one embodiment, when the microservice data packet is a microservice data packet that is not sensitive to latency, the microservice processing strategy includes: using a rate limiting algorithm to adjust the transmission bandwidth of the microservice data packet.

[0074] In one embodiment, when a microservice data packet involves user privacy and needs to be kept confidential, the microservice processing strategy includes: encrypting the microservice data packet using an encryption algorithm.

[0075] In one embodiment, the microservice data packets are transmitted along the kernel data packet processing path according to the set scheduling and resource allocation parameters. For example, the microservice data packets enter queues of different priorities at the physical layer.

[0076] In one embodiment, microservice data packets with different service level agreement requirements correspond to different kernel data packet processing paths. In this way, different microservice data packets will be processed and transmitted differently in user terminals and network nodes, achieving different fine-grained end-to-end SLAs.

[0077] In addition, an embodiment of the present application further provides a data transmission method, which may include but is not limited to step S201.

[0078] Step S201: Using the data processing method described above, the microservice data packet carrying the identifier is transmitted to the forwarding exit, and the microservice data packet is sent to the second network node through the forwarding exit, so that the second network node forwards the microservice data packet according to the identifier.

[0079] In one embodiment, the data transmission method can be applied to a user terminal. Taking the application of the data transmission method to a user terminal as an example, the user terminal uses the data processing method described above to transmit a microservice data packet carrying an identifier to a forwarding egress. Because different microservice data packets are transmitted to the forwarding egress via different optimal kernel data packet processing paths, the end-to-end latency of the microservice data packets can be shortened, and the differentiated processing path requirements of different microservice data packets can be met. The user terminal sends the microservice data packet to a second network node via the forwarding egress. The second network node forwards the microservice data packet based on the identifier. It should be noted that the second network node in this case is the first network node connected to the user terminal.

[0080] In one embodiment, the data transmission method can be applied to network nodes. Taking the application of the data transmission method to a first network node as an example, the first network node is the first network node connected to a user terminal. The first network node uses the data processing method described above to transmit a microservice data packet carrying an identifier to a forwarding exit. Because different microservice data packets are transmitted to the forwarding exit through different optimal kernel data packet processing paths, the end-to-end latency of the microservice data packet can be shortened, and the differentiated processing path requirements of different microservice data packets can be met. The first network node sends the microservice data packet to the second network node through the forwarding exit, and the second network node forwards the microservice data packet based on the identifier. It should be noted that the second network node in this case is a network node other than the first network node.

[0081] In one embodiment, the data transmission method is applied to a user terminal. A microservice data packet is generated by the user terminal based on an identifier, which is generated by a control unit based on an application service request data packet sent by the user terminal. For example, if the control unit is an orchestrator, upon receiving one or more identifiers generated by the orchestrator, the user terminal generates one or more corresponding microservice data packets carrying the identifiers and sends these microservice data packets. In this scenario, when an application service request occurs at the user terminal, the user terminal sends a microservice data packet carrying the identifier, and network nodes perform routing and forwarding based solely on the identifiers carried in the microservice data packets. In this scenario, the user terminal retains the logic for inter-microservice calls, and network nodes perform routing and forwarding based solely on the identifiers carried in the microservice data packets. After processing a microservice data packet, it may trigger the user terminal to send the next microservice data packet, corresponding to a chained call relationship between microservice data packets; it may also trigger the user terminal to send multiple microservice data packets, corresponding to a meshed call relationship between microservice data packets.

[0082] In one embodiment, a data transmission method is applied to a first network node, where a microservice data packet is generated by the first network node based on an application service request data packet and an identifier sent by a user terminal, and the identifier is generated by a control unit based on an application service request data packet forwarded by the first network node. Taking the control unit as an orchestrator, when the first network node receives one or more identifiers generated by the orchestrator, it will generate one or more microservice data packets carrying the identifiers and send these microservice data packets. In this scenario, when an application service request occurs on the network side, the user terminal sends an application service request data packet, and the first network node generates a microservice data packet carrying the identifier based on the application service request data packet, and routes and forwards the microservice data packet based on the identifier. In this scenario, the user terminal does not retain the mutual call logic between microservices. Instead, the network node generates the next microservice data packet during the microservice data packet processing process based on the identifier carried in the microservice data packet, and routes the microservice data packet to the appropriate cloud server for processing.

[0083] In one embodiment, as shown in FIG7A , after the user terminal receives the three identifiers ID A, ID B, and ID C generated by the control unit, it generates a first microservice data packet carrying the identifier ID A (the triangle shown in the figure), a second microservice data packet carrying the identifier ID B (the diamond shown in the figure), and a third microservice data packet carrying the identifier ID C (the five-pointed star shown in the figure). During the transmission of the first microservice data packet, the second microservice data packet, and the third microservice data packet along the kernel data packet processing path, they pass through the transport layer, the network layer, and the physical layer in sequence and are transmitted to the forwarding exit. The forwarding exit is connected to the first network node, which is the first network node connected to the user terminal. It should be noted that the control unit can determine the microservice processing strategy for each microservice data packet based on the current network resource status and computing power resource status. For example, as shown in the table in FIG7A , the optimal routing policy corresponding to ID A is policy a, the target address corresponding to policy a is cloud gateway GWA, and the next hop is router E; the optimal routing policy corresponding to ID B is policy b, the target address corresponding to policy b is cloud gateway GWA, and the next hop is router E; the optimal routing policy corresponding to ID C is policy c, the target address corresponding to policy c is cloud gateway GWB, and the next hop is router F. Based on this, the user terminal sends the microservice data packet to the first network node through the forwarding egress, and the first network node forwards the microservice data packet according to the identifier. That is, the first network node routes the first microservice data packet to router E according to the optimal routing policy a corresponding to ID A; the first network node routes the second microservice data packet to router E according to the optimal routing policy b corresponding to ID B; and the first network node routes the third microservice data packet to router F according to the optimal routing policy c corresponding to ID C. In this embodiment, by moving the location of generating microservice data packets for a given application from the cloud API gateway to the user terminal and carrying an identifier in the generated microservice data packets, differentiated transmission of microservice data packets in scenarios such as cross-DC communication and edge computing is achieved, thereby meeting the fine-grained SLA requirements of the application.

[0084] In one embodiment, as shown in FIG7B , a user terminal sends an application service request packet to a first network node, which is the first network node connected to the user terminal. The first network node generates microservice packets carrying identifiers based on the application service request packet. The microservice packets include a first microservice packet carrying identifier ID A (shown as a triangle in the figure), a second microservice packet carrying identifier ID B (shown as a diamond in the figure), and a third microservice packet carrying identifier ID C (shown as a five-pointed star in the figure). Identifiers ID A, ID B, and ID C are generated by a control unit based on the application service request packet forwarded by the first network node. During transmission along the kernel packet processing path, the first, second, and third microservice packets sequentially pass through the transport layer, network layer, and physical layer before being transmitted to a forwarding egress. The forwarding egress is connected to a second network node, which is another network node connected to the first network node. It should be noted that the control unit can determine the microservice processing strategy for each microservice packet based on the current network resource status and computing resource status. For example, as shown in the table in FIG7B , the optimal routing policy corresponding to ID A is policy a, the target address corresponding to policy a is cloud gateway GWA, and the next hop is router E; the optimal routing policy corresponding to ID B is policy b, the target address corresponding to policy b is cloud gateway GWA, and the next hop is router E; the optimal routing policy corresponding to ID C is policy c, the target address corresponding to policy c is cloud gateway GWB, and the next hop is router F. Based on this, the first network node sends the microservice data packet to the second network node through the forwarding egress, and the second network node forwards the microservice data packet based on the identifier. That is, the second network node routes the first microservice data packet to router E based on the optimal routing policy a corresponding to ID A; the second network node routes the second microservice data packet to router E based on the optimal routing policy b corresponding to ID B; and the second network node routes the third microservice data packet to router F based on the optimal routing policy c corresponding to ID C. In this embodiment, by moving the location of generating microservice data packets for a given application from the cloud API gateway to the network node and carrying an identifier in the generated microservice data packets, differentiated transmission of microservice data packets in scenarios such as cross-DC communication and edge computing is achieved, thereby meeting the fine-grained SLA requirements of the application.

[0085] In one embodiment, the identifier is obtained from the control unit, and the identifier carries the microservice semantic information. The control unit is deployed in the network. It should be noted that the control unit includes but is not limited to an orchestrator. Taking the control unit as an orchestrator as an example, as shown in FIG7C , an orchestrator is deployed in the network. The orchestrator may include a readable domain name and address mapping module, an application sub-function logical semantic management module, a microservice registration module, and a routing decision module, which are used to respectively implement functions such as application readable domain name and address mapping, application sub-function logical semantic management, microservice registration, and routing decision. The orchestrator regularly maintains the link between it and the routers in the network. For example, the orchestrator regularly broadcasts its IP address to the routers.

[0086] In one embodiment, as shown in Figure 8, assuming the control unit is an orchestrator, when creating a new application, the application developer registers the application with the orchestrator and declares the application's microservice composition, the inter-microservice call relationships, and the IP address of the server that handles each microservice. Within the orchestrator, the microservice registration module records the application's microservice composition and inter-microservice call relationships, while the readable domain name and address mapping module records the server's IP address.

[0087] In one embodiment, as shown in Figure 9, taking the orchestrator as the control unit, when a user terminal launches an application, it sends an application service request to the orchestrator. Within the orchestrator, the readable domain name and address mapping module receives the application service request and notifies the application sub-function logical semantic management module to process it. The application sub-function logical semantic management module accesses the microservice registration module to obtain the application's microservice components and information about inter-microservice calls. Based on this information, it generates one or more microservice requests. The application sub-function logical semantic management module then sends the microservice request to the readable domain name and address mapping module and the routing decision module, respectively.

[0088] In one embodiment, when a microservice request returns to the routing decision module, the optimal routing strategy is determined based on the current network resource status and computing power resource status. When a microservice request returns to the application-readable domain name and address mapping module, an identifier in the target address format is generated, which carries the semantic information of the microservice.

[0089] In one embodiment, as shown in FIG10 , the orchestrator configures routers in the network according to all generated routing policies, and returns all generated identifiers as target addresses to the user terminal.

[0090] In one embodiment, the microservice processing strategy can be obtained by the control unit based on the current network resource status and computing resource status, or can be pre-configured by the control unit.

[0091] As shown in FIG. 11 , FIG. 11 is a flowchart of a data transmission method provided by an embodiment of the present application. The data transmission method may include but is not limited to steps S301 to S302 .

[0092] Step S301: receiving a microservice data packet carrying an identifier;

[0093] Step S302: Using the data processing method described above, the microservice data packet is transmitted to the forwarding exit, and the microservice data packet is sent to the third network node through the forwarding exit, so that the third network node processes the microservice data packet according to the identifier.

[0094] In one embodiment, this data transmission method can be applied to a network node. The network node receives a microservice data packet carrying an identifier and, using the data processing method described above, transmits the microservice data packet to a forwarding egress. Because different microservice data packets are transmitted to the forwarding egress via different optimal kernel data packet processing paths, this method can shorten the end-to-end latency of the microservice data packets and meet the differentiated processing path requirements of different microservice data packets. Furthermore, the network node sends the microservice data packet to a third network node via the forwarding egress, which processes the microservice data packet based on the identifier. The third network node can be a network node other than the first network node connected to the user terminal, or a cloud server. If the third network node is another network node, the third network node forwards and processes the microservice data packet based on the identifier. If the third network node is a cloud server, the third network node invokes and processes the microservice data packet based on the identifier.

[0095] As shown in FIG. 12 , an embodiment of the present application further illustrates step S302 , which includes but is not limited to steps S401 to S402 .

[0096] Step S401: Update the target address to the cloud server address of the third network node to obtain an updated microservice data packet;

[0097] Step S402: Send the updated microservice data packet to the third network node through the forwarding egress.

[0098] In this step, the third network node is a cloud server, and the microservice data packet includes a destination address. The network node updates the destination address to the cloud server address, obtains an updated microservice data packet, and sends the updated microservice data packet to the cloud server via a forwarding egress.

[0099] In one embodiment, the network node can send received microservice data packets to the cloud gateway node based on the routing policy configured by the control unit. The cloud gateway node resolves the destination address, selects an appropriate cloud server based on current cloud resource usage, and replaces the destination address of the microservice data packet with the cloud server address. The cloud gateway node then sends the microservice data packet, which is then routed and forwarded within the cloud gateway's network until it reaches the target cloud server.

[0100] In one embodiment, the embodiment of the present application can support multiple application scenarios. Three typical application scenarios are: as shown in Figure 13A, the cloud server node of the microservice can be deployed in a DC (Data Center); as shown in Figure 13B, the cloud server node of the microservice can also be deployed in multiple DCs; as shown in Figure 13C, the cloud server node of the microservice can also be deployed in an edge DC. In the above application scenarios, for any given application, the process of generating microservice data packets occurs in a module related to sub-function semantic logic management. The module can be deployed in a variety of possible locations, including but not limited to in a user terminal or a network node, and the network node may include an edge gateway or orchestrator of the network.

[0101] In one embodiment, as shown in FIG7A , after the user terminal receives the three identifiers ID A, ID B, and ID C generated by the control unit, it generates a first microservice data packet carrying the identifier ID A (the triangle shown in the figure), a second microservice data packet carrying the identifier ID B (the diamond shown in the figure), and a third microservice data packet carrying the identifier ID C (the five-pointed star shown in the figure). During the transmission of the first microservice data packet, the second microservice data packet, and the third microservice data packet along the kernel data packet processing path, they pass through the transport layer, the network layer, and the physical layer in sequence and are transmitted to the forwarding exit. The forwarding exit is connected to the first network node, which is the first network node connected to the user terminal. It should be noted that the control unit can determine the microservice processing strategy for each microservice data packet based on the current network resource status and computing power resource status. For example, as shown in the table in Figure 7A, the best routing policy corresponding to identifier ID A is policy a, the target address corresponding to policy a is the cloud gateway GWA, and the next hop is router E; the best routing policy corresponding to identifier ID B is policy b, the target address corresponding to policy b is the cloud gateway GWA, and the next hop is router E; the best routing policy corresponding to identifier ID C is policy c, the target address corresponding to policy c is the cloud gateway GWB, and the next hop is router F. Based on this, the user terminal sends the microservice data packet to the first network node through the forwarding exit. The first network node forwards the microservice data packet according to the identifier, that is, the first network node routes the first microservice data packet to router E according to the optimal routing policy policy a corresponding to identifier ID A. Router E updates the destination address to the cloud server address in cloud gateway A, obtains the updated first microservice data packet, and sends the updated first microservice data packet to cloud server A through the forwarding exit; the first network node routes the second microservice data packet to router E according to the optimal routing policy policy b corresponding to identifier ID B. Router E updates the destination address to the cloud server address in cloud gateway A, obtains the updated second microservice data packet, and sends the updated second microservice data packet to cloud server A through the forwarding exit; the first network node routes the third microservice data packet to router F according to the optimal routing policy policy c corresponding to identifier ID C. Router F updates the destination address to the cloud server address in cloud gateway B, obtains the updated third microservice data packet, and sends the updated third microservice data packet to cloud server B through the forwarding exit. In this embodiment, by moving the location of generating microservice data packets for a given application from the cloud API gateway to the user terminal and carrying an identifier in the generated microservice data packets, differentiated transmission of microservice data packets in scenarios such as cross-DC communication and edge computing is achieved, thereby meeting the fine-grained SLA requirements of microservice applications from end to network to cloud.

[0102] In one embodiment, as shown in FIG7B , a user terminal sends an application service request packet to a first network node, which is the first network node connected to the user terminal. The first network node generates microservice packets carrying identifiers based on the application service request packet. The microservice packets include a first microservice packet carrying identifier ID A (a triangle in the figure), a second microservice packet carrying identifier ID B (a diamond in the figure), and a third microservice packet carrying identifier ID C (a five-pointed star in the figure). Identifiers ID A, ID B, and ID C are generated by a control unit based on the application service request packet forwarded by the first network node. During transmission along the kernel packet processing path, the first, second, and third microservice packets sequentially pass through the transport layer, network layer, and physical layer before being transmitted to a forwarding egress. The forwarding egress is connected to a second network node, which is another network node connected to the first network node. It should be noted that the control unit can determine the microservice processing strategy for each microservice packet based on the current network resource status and computing resource status. For example, as shown in the table in Figure 7B, the best routing policy corresponding to identifier ID A is policy a, the target address corresponding to policy a is the cloud gateway GWA, and the next hop is router E; the best routing policy corresponding to identifier ID B is policy b, the target address corresponding to policy b is the cloud gateway GWA, and the next hop is router E; the best routing policy corresponding to identifier ID C is policy c, the target address corresponding to policy c is the cloud gateway GWB, and the next hop is router F. Based on this, the first network node sends the microservice data packet to the second network node through the forwarding exit, and the second network node forwards the microservice data packet according to the identifier, that is, the second network node routes the first microservice data packet to router E according to the optimal routing policy policy a corresponding to identifier ID A, and router E updates the destination address to the cloud server address in cloud gateway A, obtains the updated first microservice data packet, and sends the updated first microservice data packet to cloud server A through the forwarding exit; the second network node routes the second microservice data packet to router E according to the optimal routing policy policy b corresponding to identifier ID B, and router E updates the destination address to the cloud server address in cloud gateway A, obtains the updated second microservice data packet, and sends the updated second microservice data packet to cloud server A through the forwarding exit; the second network node routes the third microservice data packet to router F according to the optimal routing policy policy c corresponding to identifier ID C, and router F updates the destination address to the cloud server address in cloud gateway B, obtains the updated third microservice data packet, and sends the updated third microservice data packet to cloud server B through the forwarding exit.In this embodiment, by moving the location of generating microservice data packets for a given application from the cloud API gateway to the network node and carrying an identifier in the generated microservice data packet, differentiated transmission of microservice data packets in scenarios such as cross-DC communication and edge computing is achieved, thereby meeting the fine-grained SLA requirements of microservice applications from end to network to cloud.

[0103] It should be noted that the data processing method and data transmission method of the embodiments of the present application can be applied to microservice data packets, and can also be applied to other types of data packets similar to the microservice call mechanism.

[0104] In addition, as shown in FIG14 , an embodiment of the present application further discloses a communication device, comprising: at least one processor 210; at least one memory 220 for storing at least one program; when the at least one program is executed by the at least one processor 210, a data processing method as in any of the previous embodiments is implemented, or a data transmission method as in any of the previous embodiments is implemented. It should be noted that the communication device includes a user terminal or a network node.

[0105] In addition, an embodiment of the present application further discloses a computer-readable storage medium storing computer-executable instructions for executing the data processing method or the data transmission method in any of the foregoing embodiments.

[0106] The system architecture and application scenarios described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided in the embodiments of the present application. Those skilled in the art will appreciate that with the evolution of the system architecture and the emergence of new application scenarios, the technical solutions provided in the embodiments of the present application are equally applicable to similar technical problems.

[0107] Those skilled in the art will appreciate that all or some of the steps in the methods, systems, and functional modules / units in the devices disclosed above may be implemented as software, firmware, hardware, or appropriate combinations thereof.

[0108] In a hardware implementation, the division between the functional modules / units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium). As known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, as is well known to those skilled in the art, communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.

[0109] As used in this specification, the terms "component," "module," "system," and the like are used to refer to computer-related entities, hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, or a computer. By way of illustration, both applications running on a computing device and a computing device can be components. One or more components can reside in a process or execution thread, and a component can be located on one computer or distributed between two or more computers. In addition, these components can be executed from various computer-readable media having various data structures stored thereon. Components can communicate, for example, through local or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component on a local system, a distributed system, or a network, such as the Internet interacting with other systems via signals).

Claims

1. A data processing method, comprising: When a microservice data packet carrying an identifier is obtained, microservice semantic information of the microservice data packet is determined according to the identifier; Determine a kernel data packet processing path of the microservice data packet according to the microservice semantic information and the microservice processing strategy; The microservice data packet is transmitted to the forwarding exit according to the kernel data packet processing path.

2. The method according to claim 1, wherein: The data processing method is applied to a user terminal or a network node.

3. The method according to claim 1, wherein: During the transmission of the microservice data packet along the kernel data packet processing path, the microservice data packet passes through the transport layer, the network layer and the physical layer in sequence.

4. The method according to claim 1, wherein: The identifier is obtained from a control unit, and the identifier carries the microservice semantic information.

5. The method according to claim 1, wherein: The microservice processing strategy is obtained by the control unit according to the current network resource status and computing power resource status.

6. The method according to claim 1, wherein: When the microservice data packet is a delay-sensitive microservice data packet, the microservice processing strategy includes: in the kernel, using an extended Berkeley packet filter to redirect and control the flow of the microservice data packet.

7. The method according to claim 1, wherein: When the microservice data packet is a microservice data packet that is not sensitive to delay, the microservice processing strategy includes: using a rate limiting algorithm to adjust the transmission bandwidth of the microservice data packet.

8. The method according to claim 1, wherein: The microservice data packet is transmitted along the kernel data packet processing path according to the set scheduling and resource allocation parameters.

9. The method according to any one of claims 1 to 8, wherein: The microservice data packets with different service level agreement requirements correspond to different kernel data packet processing paths.

10. A data transmission method, comprising: Using the data processing method described in any one of claims 1 to 9, a microservice data packet carrying an identifier is transmitted to a forwarding exit, and the microservice data packet is sent to a second network node through the forwarding exit, so that the second network node forwards the microservice data packet according to the identifier.

11. The method according to claim 10, wherein: The data transmission method is applied to a user terminal, the microservice data packet is generated by the user terminal according to the identifier, and the identifier is generated by a control unit according to an application service request data packet sent by the user terminal.

12. The method according to claim 10, wherein: The data transmission method is applied to a first network node, the microservice data packet is generated by the first network node according to an application service request data packet sent by a user terminal and the identifier, and the identifier is generated by a control unit according to the application service request data packet forwarded by the first network node.

13. A data transmission method, comprising: Receive microservice data packets carrying identifiers; Adopting the data processing method as described in any one of claims 1 to 9, the microservice data packet is transmitted to a forwarding exit, and the microservice data packet is sent to a third network node through the forwarding exit, so that the third network node processes the microservice data packet according to the identifier.

14. The method according to claim 13, wherein: The third network node is a cloud server, the microservice data packet includes a target address; and sending the microservice data packet to the third network node through the forwarding egress includes: Updating the target address to the cloud server address of the third network node to obtain an updated microservice data packet; The updated microservice data packet is sent to the third network node through the forwarding egress.

15. A communication device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the data processing method according to any one of claims 1 to 9 or the data transmission method according to any one of claims 10 to 14 is implemented.

16. A computer-readable storage medium storing computer-executable instructions, wherein: The computer executable instructions are used to execute the data processing method according to any one of claims 1 to 9, or the data transmission method according to any one of claims 10 to 14.

Images