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

Abstract

The embodiment of the invention provides a data processing method, a data transmission method, communication equipment and a storage medium. The data processing method comprises the following steps: under the condition that a micro-service data packet carrying an identifier is obtained, determining micro-service semantic information of the micro-service data packet according to the identifier, and determining a kernel data packet processing path of the micro-service data packet according to the micro-service semantic information and a micro-service processing strategy, and transmitting the micro-service data packet to a forwarding outlet according to the kernel data packet processing path. Different micro-service data packets are transmitted to the forwarding outlet through different optimal kernel data packet processing paths, so that the end-to-end time delay of the micro-service data packets can be shortened, and the differentiated processing path requirements of different micro-service data packets can be met.

Description

Technical Field

[0001] 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

[0002] In the related art, for the current mainstream microservice architecture, the call of microservice data packets occurs in 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 lead to 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. Summary of the invention

[0003] 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.

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

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

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

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

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

[0009] Using the data processing method as described in the first aspect, 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.

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

[0011] Receive microservice data packets carrying identifiers;

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

[0013] 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 executable on the processor, wherein 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.

[0014] 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.

[0015] 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: in the case of obtaining a microservice data packet carrying an identifier, determining the microservice semantic information of the microservice data packet according to the identifier, determining the kernel data packet processing path of the microservice data packet according to the microservice semantic information and the microservice processing strategy, and transmitting the microservice data packet to the forwarding exit according to the kernel data packet processing path. The data transmission method of another embodiment includes: using the aforementioned data processing method 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 aforementioned data processing method 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

[0016] Figure 1It is a schematic diagram of direct communication between a user terminal and a microservice in the related art;

[0017] Figure 2 It is a schematic diagram of a user terminal communicating with a microservice using an API gateway in the related art;

[0018] Figure 3 It is a schematic diagram of the existing packet sending and receiving path;

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

[0020] Figure 5 It is a schematic diagram of the packet sending and receiving path when the destination node is a service node on another host;

[0021] Figure 6 is a flow chart of a data processing method provided by an embodiment of the present application;

[0022] Fig. 7A This is a schematic diagram of a microservice data packet transmission route provided by an embodiment of the present application when a microservice data packet is generated by a user terminal;

[0023] Figure 7B It is a schematic diagram of a microservice data packet transmission route provided by an embodiment of the present application when a network node generates a microservice data packet;

[0024] Figure 7C It is a schematic diagram of the deployment structure of an orchestrator in which a microservice cloud server node is deployed in multiple DC scenarios provided by an embodiment of the present application;

[0025] Figure 8 This is a schematic diagram of the structure of a microservice cloud server registering an application with an orchestrator provided by an embodiment of the present application;

[0026] Fig. 9 This is a schematic diagram of the interaction between the modules inside the orchestrator after the user terminal starts the application according to an embodiment of the present application;

[0027] Fig.10 It is a schematic diagram of an orchestrator returning a microservice identifier and configuring a router provided by an embodiment of the present application;

[0028] Fig.11 is a flow chart of a data transmission method provided by an embodiment of the present application;

[0029] Fig.12 This is an embodiment of the present application. Fig.11 Flow chart of step S302 in FIG.

[0030] Fig.13AThis is a schematic diagram of a microservice cloud server node deployed in a DC scenario provided by an embodiment of the present application;

[0031] Fig. 13B It is a schematic diagram of deploying a microservice cloud server node in multiple DC scenarios provided by an embodiment of the present application;

[0032] Fig. 13C This is a schematic diagram of deploying a microservice cloud server node under an edge DC provided by an embodiment of the present application;

[0033] Fig.14 It is a schematic diagram of a communication device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0034] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0035] It should be noted that, although the functional modules are divided in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first", "second", etc. in the specification and claims and the following drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.

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

[0037] 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 first given below.

[0038] Traditional developers usually consider an application as an inseparable monolith. However, as application functions become more and more complex, the above development model causes the difficulty of operating and maintaining applications to increase exponentially. To solve this problem, developers began to decompose applications into logically independent functional modules and develop each module separately. Such a module is called a "microservice". Traditional monolithic applications are usually deployed and run in a server in the cloud, while under the microservice architecture, each microservice module can be processed by servers deployed in different locations in the cloud. In this way, the functions of the original monolithic application can be realized by running microservices in sequence and enabling communication between microservices. Considering that the input parameters of a microservice may be the results of the operation of other microservices, the mutual call relationship and completion sequence between microservices have a significant impact on the function of the entire application. In addition, different microservices have different requirements for network and computing resources. Providing differentiated transmission for data packets of different microservices is very important to ensure user experience.

[0039] There are currently two ways to achieve the process from application --> determining the microservice composition of the application --> running microservices, namely, user direct completion and API gateway proxy completion. In the user direct completion method, it is necessary to pre-configure the microservice composition of each application and the calling relationship between each other, as well as the server address running each microservice on the terminal side. When the application starts, the terminal directly sends a data packet to the server of the cloud microservice to request service; while in the API gateway proxy completion method, it is necessary to pre-register the application in the API gateway, declare the microservice composition of the application and the calling relationship between each other, and save the server address running each microservice. When the application starts, the terminal sends a service request for the application to an API gateway, and the API gateway first determines the microservice composition of the application based on the reserved information, and then further sends a data packet to request service based on the calling relationship between the microservices.

[0040] The advantage of the user-direct completion method is that users can set different parameters according to the characteristics of different microservices, so that the network can transmit data packets differently according to these parameters. However, the disadvantage is that the development of the application is not transparent to the user. Whenever the composition of the microservices of the application or the mutual calling relationship changes, the user needs to update the configuration. In addition, when the number of microservices that make up the application is large or the mutual calling relationship between the microservices is 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 achieve complete transparency of application development to users and avoid frequent data packet transmission between the terminal and the cloud server, but the disadvantage is that the network cannot provide fine-grained services at the microservice level. In addition, the API gateway needs to parse the service request data packet of the application at the seventh layer of the protocol stack and issue a new microservice data packet. In multi-cloud communication scenarios and edge computing scenarios, data packets crossing the seven-layer protocol stack multiple times will cause a large end-to-end latency.

[0041] 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 under the constraints of limited computing power and network resources; and in order to provide 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, and there is currently no clear solution in the industry. In order to make up for the above shortcomings, it is necessary to design a simple, feasible and user-transparent application microservice disassembly, orchestration and differentiated transmission solution based on comprehensive consideration of computing power resources and network resources, and move the location of the application microservice composition from the cloud API gateway to the network or even the terminal to meet the fine-grained SLA (Service Level Agreement) requirements from end to network to cloud.

[0042] The terminal can directly make requests to the microservice, such as Figure 1 As shown, Figure 1 This is a schematic diagram of direct communication between the terminal and the microservice. This direct communication mode can meet the needs of small applications based on microservices, but there are many problems for large applications based on microservices. Four of the problems are listed below:

[0043] 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.

[0044] 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 difficulty in development and maintenance;

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

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

[0047] To solve the above problems, you can introduce an API gateway as the only entry point for microservices, such as Figure 2 As shown, Figure 2 Diagram of using API gateway for terminal 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.

[0048] 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. 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 packets can be redirected and flow controlled in the kernel, greatly shortening the processing path and latency of data packets, as shown below Figures 3 to 5 As shown. Among them, Figure 3 The schematic diagram of the existing packet sending and receiving path shows that the packet sending and receiving path needs to be from ① to The transmission is performed sequentially. Figure 4 This is a schematic diagram of the packet receiving and sending path using eBPF technology. When a data packet is transmitted to TCingress, it can jump directly from TC ingress to TC egress, that is, the nodes between TC ingress and TC egress can be skipped, thereby realizing data packet redirection and flow control in the kernel, greatly shortening the data packet processing path and latency. Figure 5 The diagram is a diagram of the packet sending and receiving path when the destination node is a service node on another host.

[0049] For the current mainstream microservice architecture, the call of microservice data packets occurs at the API gateway of the central cloud or data center. However, for cross-data center communication scenarios or edge computing scenarios, the above microservice architecture will lead to 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.

[0050] 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: in the case of obtaining a microservice data packet carrying an identifier, determining the microservice semantic information of the microservice data packet according to the identifier, determining the kernel data packet processing path of the microservice data packet according to the microservice semantic information and the microservice processing strategy, and transmitting the microservice data packet to the forwarding exit according to the kernel data packet processing path. The data transmission method of another embodiment includes: using the aforementioned data processing method 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 aforementioned data processing method 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.

[0051] The embodiments of the present application are further described below in conjunction with the accompanying drawings.

[0052] like Figure 6 As shown, Figure 6 It 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.

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

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

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

[0056] 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.

[0057] In one embodiment, the data processing method can be applied to a user terminal or a network node. By moving the location of generating a microservice data packet of a given application from the cloud API gateway to the network node and the user terminal, and carrying an identifier in the generated microservice data packet, the differentiated transmission of the microservice data packet in cross-DC communication, edge computing and other scenarios is achieved, thereby meeting the fine-grained SLA requirements of the application.

[0058] 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, 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. The microservice data packet is transmitted to the 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 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.

[0059] In one embodiment, the data processing method can be applied to a network node. Taking the data processing method applied 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 obtains a microservice data packet carrying an identifier. The microservice semantic information of the microservice data packet can be obtained through the identifier. 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. The microservice data packet is transmitted to a forwarding exit through the kernel data packet processing path, and the forwarding exit is connected to a second 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.

[0060] In one embodiment, 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, so that the protocol stack layer for processing the microservice data packet can be lowered from the seven layers of the API gateway to the three layers. It should be noted that during the transmission along the kernel data packet processing path, the microservice data packet passes through at least the transport layer, the network layer, and the physical layer, but is not limited to the three layers of the transport layer, the network layer, and the physical layer.

[0061] In one embodiment, if Fig. 7A As shown, after the user terminal receives the three identifiers ID A, ID B, and ID C generated by the control unit, it generates the first microservice data packet carrying the identifier ID A (the triangle shown in the figure), the second microservice data packet carrying the identifier IDB (the diamond shown in the figure), and the third microservice data packet carrying the identifier ID C (the five-pointed star shown in the figure) respectively. 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, and the first network node 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, Fig. 7A As shown in the table, the best routing policy corresponding to 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 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 ID C is policy c, the target address corresponding to policy c is the cloud gateway GWB, and the next hop is router F.

[0062] In one embodiment, if Figure 7B As shown, the user terminal sends an application service request data packet to the first network node, and the first network node is the first network node connected to the user terminal. The first network node generates a microservice data packet carrying an identifier based on the application service request data packet, and the microservice data packet includes a first microservice data packet carrying an identifier ID A (the triangle shown in the figure), a second microservice data packet carrying an identifier ID B (the diamond shown in the figure), and a third microservice data packet carrying an identifier ID C (the five-pointed star shown in the figure), wherein the identifiers ID A, ID B, and ID C are generated by the control unit based on the application service request data packet forwarded by the first network node. 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, and the forwarding exit is connected to the second network node, and the second network node 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 data packet based on the current network resource status and computing power resource status. For example, as Figure 7B As shown in the table, the best routing policy corresponding to 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 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 ID C is policy c, the target address corresponding to policy c is the cloud gateway GWB, and the next hop is router F.

[0063] 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 the orchestrator. For example, if the control unit is the orchestrator, Figure 7C As shown, an orchestrator is deployed in the network. The orchestrator may include a readable domain name and address mapping module, an application sub-function logic 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 logic semantic management, microservice registration, and routing decision. The orchestrator regularly maintains the link between it and the router in the network. For example, the orchestrator regularly broadcasts its IP address to the router.

[0064] In one embodiment, if Figure 8As shown, taking the control unit as an orchestrator as an example, when a new application is generated, the application developer registers the application with the orchestrator and declares the microservice composition of the application, the mutual calling relationship between microservices, and the server IP address that processes each microservice. In the orchestrator, the microservice registration module records the microservice composition of the application and the mutual calling relationship between microservices, and the readable domain name and address mapping module records the IP address of the server.

[0065] In one embodiment, if Fig. 9 As shown, taking the control unit as an orchestrator as an example, when the user terminal starts the application, it sends an application service request to the orchestrator. In the orchestrator, after receiving the application service request, the readable domain name and address mapping module notifies the application sub-function logic semantic management module to process it. The application sub-function logic semantic management module accesses the microservice registration module to obtain the microservice composition of the application and the mutual call information between microservices, and generates one or more microservice requests based on the information. The application sub-function logic semantic management module sends the microservice request to the readable domain name and address mapping module and the routing decision module respectively.

[0066] In one embodiment, when a microservice request returns to the routing decision module, the best routing strategy will be derived 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 related module, an identifier in the target address format will be generated, which carries the semantic information of the microservice.

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

[0068] In one embodiment, the microservice processing strategy can be obtained by the control unit according to the current network resource status and computing power resource status, or can be pre-configured by the control unit.

[0069] 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, an extended Berkeley packet filter is used 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 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 processing path and latency of the data packet. Exemplarily, for delay-sensitive microservice data packets, eBPF technology can be used to enable microservice data packets to be processed directly in the kernel to avoid switching between user mode and kernel mode.

[0070] 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.

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

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

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

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

[0075] Step S201: using the data processing method as described above, transmitting 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.

[0076] 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 adopts the data processing method as described above to transmit the microservice data packet carrying the identifier to the forwarding exit. 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. The user terminal 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. It should be noted that the second network node in this case is the first network node connected to the user terminal.

[0077] In one embodiment, the data transmission method can be applied to a network node. Taking the application of the data transmission method to the first network node as an example, the first network node is the first network node connected to the user terminal. The first network node adopts the data processing method as described above to transmit the microservice data packet carrying the identifier to the forwarding exit. 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. 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. It should be noted that the second network node in this case is a network node other than the first network node.

[0078] In one embodiment, the data transmission method is applied to a user terminal, and a microservice data packet is generated by the user terminal according to an identifier, and the identifier is generated by the control unit according to an application service request data packet sent by the user terminal. Taking the control unit as an orchestrator as an example, when the user terminal receives one or more identifiers generated by the orchestrator, one or more microservice data packets carrying the identifiers will be generated accordingly, and these microservice data packets will be sent out. In this case, when the application service request occurs in the user terminal, the microservice data packet carrying the identifier is sent out by the user terminal, and the network node only routes and forwards according to the identifier carried by the microservice data packet. In this case, the user terminal retains the mutual call logic between microservices, and the network node only routes and forwards according to the identifier carried in the microservice data packet. When a microservice data packet is processed, it may trigger the user terminal to send the next microservice data packet, corresponding to the chain call relationship between the microservice data packets; it may also trigger the user terminal to send multiple microservice data packets, corresponding to the mesh call relationship between the microservice data packets.

[0079] In one embodiment, the data transmission method is applied to the first network node, and the microservice data packet is generated by the first network node according to the application service request data packet and the identifier sent by the user terminal, and the identifier is generated by the control unit according to the application service request data packet forwarded by the first network node. Taking the control unit as an orchestrator as an example, 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 case, when the 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 according to the application service request data packet, and routes and forwards the microservice data packet according to the identifier. In this case, the user terminal does not retain the mutual call logic between microservices, but the network node generates the next microservice data packet during the microservice data packet processing according to the identifier carried in the microservice data packet, and routes the microservice data packet to the appropriate cloud server for processing.

[0080] In one embodiment, if Fig. 7A As shown, after the user terminal receives the three identifiers ID A, ID B, and ID C generated by the control unit, it generates the first microservice data packet carrying the identifier ID A (the triangle shown in the figure), the second microservice data packet carrying the identifier IDB (the diamond shown in the figure), and the third microservice data packet carrying the identifier ID C (the five-pointed star shown in the figure) respectively. 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, and the first network node 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, Fig. 7AAs shown in the table, the best routing policy corresponding to the 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 the 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 the 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, 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 best routing policy policy a corresponding to the identifier ID A; the first network node routes the second microservice data packet to router E according to the best routing policy policy b corresponding to the identifier ID B; the first network node routes the third microservice data packet to router F according to the best routing policy policy c corresponding to the identifier ID C. In this embodiment, by moving the location where the microservice data packet for a given application is generated from the cloud API gateway to the user terminal 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 the application.

[0081] In one embodiment, if Figure 7B As shown, the user terminal sends an application service request data packet to the first network node, and the first network node is the first network node connected to the user terminal. The first network node generates a microservice data packet carrying an identifier based on the application service request data packet, and the microservice data packet includes a first microservice data packet carrying an identifier ID A (the triangle shown in the figure), a second microservice data packet carrying an identifier ID B (the diamond shown in the figure), and a third microservice data packet carrying an identifier ID C (the five-pointed star shown in the figure), wherein the identifiers ID A, ID B, and ID C are generated by the control unit based on the application service request data packet forwarded by the first network node. 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, and the forwarding exit is connected to the second network node, and the second network node 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 data packet based on the current network resource status and computing power resource status. For example, as Figure 7BAs shown in the table, the best routing policy corresponding to the 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 the 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 the 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 best routing policy policy a corresponding to the identifier ID A; the second network node routes the second microservice data packet to router E according to the best routing policy policy b corresponding to the identifier ID B; the second network node routes the third microservice data packet to router F according to the best routing policy policy c corresponding to the identifier ID C. In this embodiment, by moving the location for 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 the application.

[0082] 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 the orchestrator. For example, if the control unit is the orchestrator, Figure 7C As shown, an orchestrator is deployed in the network. The orchestrator may include a readable domain name and address mapping module, an application sub-function logic 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 logic semantic management, microservice registration, and routing decision. The orchestrator regularly maintains the link between it and the router in the network. For example, the orchestrator regularly broadcasts its IP address to the router.

[0083] In one embodiment, if Figure 8 As shown, taking the control unit as an orchestrator as an example, when a new application is generated, the application developer registers the application with the orchestrator and declares the microservice composition of the application, the mutual calling relationship between microservices, and the server IP address that processes each microservice. In the orchestrator, the microservice registration module records the microservice composition of the application and the mutual calling relationship between microservices, and the readable domain name and address mapping module records the IP address of the server.

[0084] In one embodiment, if Fig. 9As shown, taking the control unit as an orchestrator as an example, when the user terminal starts the application, it sends an application service request to the orchestrator. In the orchestrator, after receiving the application service request, the readable domain name and address mapping module notifies the application sub-function logic semantic management module to process it. The application sub-function logic semantic management module accesses the microservice registration module to obtain the microservice composition of the application and the mutual call information between microservices, and generates one or more microservice requests based on the information. The application sub-function logic semantic management module sends the microservice request to the readable domain name and address mapping module and the routing decision module respectively.

[0085] In one embodiment, when a microservice request returns to the routing decision module, the best routing strategy will be derived 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 related module, an identifier in the target address format will be generated, which carries the semantic information of the microservice.

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

[0087] In one embodiment, the microservice processing strategy can be obtained by the control unit according to the current network resource status and computing power resource status, or can be pre-configured by the control unit.

[0088] like Fig.11 As shown, Fig.11 It 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.

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

[0090] Step S302: using the data processing method as 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.

[0091] In one embodiment, the data transmission method can be applied to a network node, the network node receives a microservice data packet carrying an identifier, and the network node adopts the data processing method as described above to transmit the microservice data packet to a forwarding exit. 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. In addition, the network node sends the microservice data packet to a third network node through the forwarding exit, and the third network node processes the microservice data packet according to the identifier. Among them, the third network node can be other network nodes except the first network node connected to the user terminal, or it can be a cloud server. In the case where the third network node is other network nodes, the third network node forwards the microservice data packet according to the identifier. In the case where the third network node is a cloud server, the third network node calls and processes the microservice data packet according to the identifier.

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

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

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

[0095] In this step, the third network node is a cloud server, and the microservice data packet includes a target address. The network node updates the target address to the cloud server address, obtains an updated microservice data packet, and sends the updated microservice data packet to the cloud server through a forwarding exit.

[0096] In one embodiment, the network node can send the received microservice data packet to the cloud gateway node according to the routing policy configured by the control unit. The cloud gateway node parses the target address, selects a suitable cloud server according to the current resource usage in the cloud, and replaces the target address of the microservice data packet with the cloud server address. Subsequently, the cloud gateway node sends out the microservice data packet, and the microservice data packet is routed and forwarded in the network within the cloud gateway until it reaches the target cloud server.

[0097] In one embodiment, the present application embodiment can support multiple application scenarios. Three typical application scenarios are: Fig.13A As shown in Figure 1, the cloud server nodes of microservices can be deployed in a DC (Data Center); Fig. 13BAs shown, the cloud server nodes of microservices can also be deployed in multiple DCs; Fig. 13C As shown, the cloud server node of the microservice can also be deployed in the edge DC. In the above application scenario, for any given application, the process of generating a microservice data packet occurs in a module related to the 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, which can include an edge gateway or an orchestrator of the network.

[0098] In one embodiment, if Fig. 7A As shown, after the user terminal receives the three identifiers ID A, ID B, and ID C generated by the control unit, it generates the first microservice data packet carrying the identifier ID A (the triangle shown in the figure), the second microservice data packet carrying the identifier IDB (the diamond shown in the figure), and the third microservice data packet carrying the identifier ID C (the five-pointed star shown in the figure) respectively. 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, and the first network node 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, Fig. 7AAs shown in the table, the best routing policy corresponding to 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 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 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, 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 policy a corresponding to identifier ID A, and router E updates the target address to the cloud server address in cloud gateway A to obtain an 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, and router E updates the target address to the cloud server address in cloud gateway A to obtain an 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, and router F updates the target address to the cloud server address in cloud gateway B to obtain an 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 where microservice data packets for a given application are generated from the cloud API gateway to the user terminal 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.

[0099] In one embodiment, if Figure 7BAs shown, the user terminal sends an application service request data packet to the first network node, and the first network node is the first network node connected to the user terminal. The first network node generates a microservice data packet carrying an identifier based on the application service request data packet, and the microservice data packet includes a first microservice data packet carrying an identifier ID A (the triangle shown in the figure), a second microservice data packet carrying an identifier ID B (the diamond shown in the figure), and a third microservice data packet carrying an identifier ID C (the five-pointed star shown in the figure), wherein the identifiers ID A, ID B, and ID C are generated by the control unit based on the application service request data packet forwarded by the first network node. 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, and the forwarding exit is connected to the second network node, and the second network node 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 data packet based on the current network resource status and computing power resource status. For example, as Figure 7BAs shown in the table, the best routing policy corresponding to 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 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 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 target address to the cloud server address in cloud gateway A to obtain 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 target address to the cloud server address in cloud gateway A to obtain 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 target address to the cloud server address in cloud gateway B to obtain 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 for 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.

[0100] 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.

[0101] In addition, if Fig.14 As shown, an embodiment of the present application also discloses a communication device, including: 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.

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

[0103] 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.

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

[0105] In 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 physical components 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 of ordinary skill 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 include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, 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, it is well known to those skilled in the art that 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.

[0106] The terms "component", "module", "system", etc. used in this specification are used to represent 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 may reside in a process or an execution thread, and a component may be located on a computer or distributed between two or more computers. In addition, these components may be executed from various computer-readable media having various data structures stored thereon. Components may 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 between a local system, a distributed system, or a network, such as the Internet interacting with other systems through 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, characterized in that The data processing method is applied to a user terminal or a network node.

3. The method according to claim 1, characterized in that 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, characterized in that: The identifier is obtained from a control unit, and the identifier carries the microservice semantic information.

5. The method according to claim 1, characterized in that 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, characterized in that 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, characterized in that 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, characterized in that 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, characterized in that: 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, characterized in that 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, characterized in that 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, characterized in that 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 the processor implements the data processing method as described in any one of claims 1 to 9, or the data transmission method as described in any one of claims 10 to 14 when executing the computer program.

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