Microservice-based service mesh system and service governance method

Abstract

The application relates to the technical field of data processing, in particular to a service grid system based on micro services and a service management method. The system comprises a first node, the first node comprises a first host and a first data card, the first data card is inserted into the first host, the first data card and the first host are provided with a first data channel, the first host runs a first container group, the first container group is provided with a first micro service, the first data card accesses a network, receives a service management strategy sent by a control node through the network, and performs service management on a first access request sent by the first host to the first data card through the first data channel according to the service management strategy, wherein the first access request is an access request of the first micro service from the first container group to a second micro service. The system performs service management on the access request from the host through the data card inserted into the host, saves the resources of the host, and improves the efficiency of service management.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a microservice service mesh system and service governance method. Background Technology

[0002] Service mesh technology is an application networking technology built on top of traditional Internet Protocol (IP) networks. With service mesh technology, service discovery and routing are no longer directly based on IP addresses, but rather on service metadata information (including but not limited to service name, version, etc.). Service mesh technology decouples non-functional service governance logic from business processes in distributed applications of microservice architecture into sidecars, providing non-intrusive capabilities for service connectivity, security, flow control, canary releases, and observation, thereby achieving lightweight business operations and infrastructure-based service governance.

[0003] As user needs evolve, the scale and complexity of microservices are also growing rapidly. How to efficiently govern microservices during continuous operation is a crucial issue in the evolution of service mesh technology. Summary of the Invention

[0004] This application provides a microservice-based service mesh system and service governance method, which can use a host-independent data card to perform service governance on access requests, thereby saving host resources and improving the efficiency of service governance.

[0005] In a first aspect, embodiments of this application provide a microservice-based service mesh system, including a first node. The first node includes a first host and a first data card. The first data card is inserted into the first host, and a first data channel is established between the first data card and the first host. A first container group runs on the first host, and a first microservice is configured in the first container group. The first data card is connected to the network and receives service governance policies sent by a management node through the network. It performs service governance on a first access request sent by the first host to the first data card via the first data channel according to the service governance policies. The first access request is an access request from the first microservice obtained by the first host from the first container group for a second microservice.

[0006] In other words, nodes in this service mesh system can utilize the host's peripheral devices to perform service governance on access requests, thereby avoiding the consumption of host resources by service governance of access requests and improving the efficiency of service governance.

[0007] In one possible implementation, the service governance strategy includes the mapping between the network addresses of the second microservice and the second container group running the second microservice. The first data card is used to confirm the network address of the second container group running the second microservice according to the service governance strategy, set the destination address of the first access request to the network address of the second container group, confirm that the second container group is set on the first host, and send the modified first access request to the second container group through the first data channel.

[0008] In other words, in this implementation, the data card can perform service governance on calls between different microservices on the same node.

[0009] In one possible implementation, the service governance strategy also includes the mapping between the network addresses of the third microservice and the third container group running the third microservice; the first host is further configured to obtain the second access request from the first container group for the third microservice, and send the second access request to the first data card through the first data channel; the first data card is configured to confirm the network address of the third container group running the third microservice according to the service governance strategy, set the destination address of the second access request to the network address of the third container group, and confirm that the third container group is not set up on the first host, and send the second access request over the network.

[0010] In other words, in this implementation, the data card can perform service governance on calls between microservices on different nodes.

[0011] In one possible implementation, the first node further includes a first network interface card (NIC), which is connected to a first data card. The first data card accesses the network through the first NIC. The first data card is used to send a second access request to the first NIC, and the first NIC is used to send the second access request through the network.

[0012] In other words, in this implementation, the data card can interact with the network through a specially configured network card, thereby saving the data card resource overhead caused by information interaction between the data card and the outside world.

[0013] In one possible implementation, the service mesh system further includes a second node, which comprises a second host, a second data card, and a second network interface card (NIC). The second data card is inserted into the second host, and a second data channel is established between the second data card and the second host. A third container group runs on the second host. The second NIC is connected to the second data card and is connected to the network. The first data card is further configured to set a service mesh identifier for a second access request if it is confirmed that the third container group is not located on the first host. The second NIC is configured to receive the second access request sent by the first NIC and, if it is confirmed that the second access request carries a service mesh identifier, send the second access request to the second data card. The second data card is configured to send the second access request to the third container group via the second data channel if it is confirmed that the third container group is located on the second host.

[0014] In other words, in this implementation, the first data card can add a service mesh identifier to the access request used to access the microservice. As a result, the peer device can quickly determine whether the access request is used to access the microservice based on whether the access request carries the service mesh identifier.

[0015] In one possible implementation, the service mesh system further includes a third node, which includes a third host. The third host and the first host are connected to the network. The first host runs a first application, and the third host runs a second application. The first host is used to obtain a third access request from the first application for the network address of the second application. If it is confirmed that the first host is not running the second application, the first host sends the third access request over the network. The third host is used to receive the third access request sent by the first host and send the third access request to the second application.

[0016] In other words, in this implementation, the service mesh system can enable calls between ordinary applications on different nodes.

[0017] In one possible implementation, a first host runs a first application and a second application. The first host is used to obtain a third access request from the first application for the network address of the second application. If it is confirmed that the first host is running the second application, the third access request is sent to the second application.

[0018] In other words, in this implementation, the service mesh system can enable calls between different ordinary applications on the same node.

[0019] In one possible implementation, the service mesh system further includes a third node, which comprises a third host and a third data card. The third data card is inserted into the third host, and a third data channel is established between the third data card and the third host. A fourth container group runs on the third host, and a fourth microservice is configured in the fourth container group. The third data card and the first host are connected to the network. The first host runs a first application. The first host is used to obtain a fourth access request from the first application for the network address of the third data card and send the fourth access request over the network. The third data card is used to receive the fourth access request sent by the first host and, based on the identifier of the fourth microservice carried in the fourth access request, send the fourth access request to the fourth microservice through the third data channel.

[0020] In other words, in this implementation, the service mesh system uses data cards to enable ordinary applications to call microservices.

[0021] In one possible implementation, the service mesh system further includes a third node, which includes a third host running a third application. The third host is connected to the network. The first host is used to obtain a fifth access request from the first microservice for the network address of the third application and send the fifth access request to the first data card through the first data channel. The first data card is used to send the fifth access request through the network. The third host is used to receive the fifth access request and send the fifth access request to the third application.

[0022] In other words, in this implementation, the service mesh system uses data cards to enable microservices to call ordinary applications.

[0023] Secondly, embodiments of this application provide a service governance method based on microservices. This method is applied to a service mesh system based on microservices. The service mesh system includes a first node, which includes a first host and a first data card. The first data card is inserted into the first host, and a first data channel is established between the first data card and the first host. A first container group runs on the first host, and a first microservice is configured within the first container group. The first data card is connected to a network. The method includes: the first data card receiving a service governance policy sent by a management node via the network; and the first data card performing service governance on a first access request sent from the first host to the first data card via the first data channel according to the service governance policy. The first access request is an access request from the first host to a second microservice obtained from the first container group by the first microservice.

[0024] In one possible implementation, the service governance strategy includes the mapping between the network addresses of the second microservice and the second container group running the second microservice; the first data card performs service governance on the first access request sent from the first host to the first data card via the first data channel according to the service governance strategy, including: the first data card confirms the network address of the second container group running the second microservice according to the service governance strategy, and sets the destination address of the first access request to the network address of the second container group; the first data card confirms that the second container group is set on the first host, and sends the modified first access request to the second container group through the first data channel.

[0025] In one possible implementation, the service governance strategy also includes the mapping between the network addresses of the third microservice and the third container group running the third microservice; the method further includes: the first host obtaining the second access request from the first container group for the third microservice from the first microservice, and sending the second access request to the first data card through the first data channel; the first data card confirming the network address of the third container group running the third microservice according to the service governance strategy, and setting the destination address of the second access request to the network address of the third container group; the first data card confirming that the third container group is not set up on the first host, and sending the second access request over the network.

[0026] In one possible implementation, the first node further includes a first network interface card (NIC), which is connected to a first data card. The first data card accesses the network through the first NIC. The first data card confirms that the third container group is not located on the first host and sends a second access request through the network, including: the first data card confirms that the third container group is not located on the first host and sends a second access request to the first NIC; the first NIC sends the second access request through the network.

[0027] In one possible implementation, the service mesh system further includes a second node, which comprises a second host, a second data card, and a second network card. The second data card is inserted into the second host, and a second data channel is established between the second data card and the second host. A third container group runs on the second host. The second network card is connected to the second data card and is connected to the network. The method further includes: if the first data card confirms that the third container group is not located on the first host, it sets a service mesh identifier for the second access request; the second network card receives the second access request sent by the first network card, and if it confirms that the second access request carries a service mesh identifier, it sends the second access request to the second data card; if the second data card confirms that the third container group is located on the second host, it sends the second access request to the third container group through the second data channel.

[0028] In one possible implementation, the service mesh system further includes a third node, which includes a third host. The third host and the first host are connected to the network. The first host runs a first application, and the third host runs a second application. The method further includes: the first host obtaining a third access request from the first application for the network address of the second application; if it is confirmed that the first host is not running the second application, it sends the third access request over the network; the third host receives the third access request sent by the first host and sends the third access request to the second application.

[0029] In one possible implementation, a first host runs a first application and a second application; the method further includes: the first host obtaining a third access request from the first application for the network address of the second application, and if it is confirmed that the first host is running the second application, sending the third access request to the second application.

[0030] In one possible implementation, the service mesh system further includes a third node, which includes a third host and a third data card. The third data card is inserted into the third host, and a third data channel is established between the third data card and the third host. A fourth container group runs on the third host, and a fourth microservice is configured in the fourth container group. The third data card and the first host are connected to the network, and a first application runs on the first host. The method further includes: the first host obtaining a fourth access request from the first application for the network address of the third data card, and sending the fourth access request over the network; the third data card receiving the fourth access request sent by the first host, and sending the fourth access request to the fourth microservice through the third data channel according to the identifier of the fourth microservice carried in the fourth access request.

[0031] In one possible implementation, the service mesh system further includes a third node, which includes a third host running a third application and connected to a network. The method further includes: a first host obtaining a fifth access request from a first microservice for the network address of the third application and sending the fifth access request to a first data card through a first data channel; the first data card sending the fifth access request through the network; and the third host receiving the fifth access request and sending it to the third application.

[0032] It is understood that the service governance method provided in the second aspect is the method executed by the nodes in the service mesh system provided in the first aspect. Therefore, the beneficial effects it can achieve can be referred to the aforementioned corresponding beneficial effects.

[0033] Thirdly, embodiments of this application provide a network node, including a host and a data card, the data card being inserted into the host; the host includes a first processor and a first memory, the first memory being used to store first computer instructions; the data card includes a second processor and a second memory, the second memory being used to store second computer instructions; when the network node is running, the first processor executes the first computer instructions, the second processor executes the second computer instructions, causing the network node to execute the method provided by the second method.

[0034] Fourthly, embodiments of this application provide a computer storage medium including computer instructions that, when executed on a network node, cause the network node to perform the method provided in the second aspect.

[0035] Fifthly, embodiments of this application provide a computer program product, wherein the program code contained in the computer program product is used by a processor in a network node to implement the method provided in the first aspect.

[0036] The service mesh system and service governance method provided in this application embodiment can use a data card with independent computing capabilities to perform service governance on access requests used to call services, so that the service governance no longer occupies the host's computing resources, saving the host's computing resources and improving the efficiency of service governance. Attached Figure Description

[0037] Figure 1 This demonstrates a service governance framework;

[0038] Figure 2 A service mesh system is shown;

[0039] Figure 3 A service mesh system is shown;

[0040] Figure 4 This application illustrates a service mesh system provided by an embodiment of the present application;

[0041] Figure 5 A method based on is shown Figure 4 The following is a flowchart of the application call process for the service mesh system;

[0042] Figure 6 This application provides a flowchart of a node initialization process.

[0043] Figure 7 This application provides an example of an application invocation flowchart.

[0044] Figure 8 This application provides an example of an application invocation flowchart.

[0045] Figure 9 This application provides an example of an application invocation flowchart.

[0046] Figure 10 This application provides an example of an application invocation flowchart.

[0047] Figure 11 This application provides an example of an application invocation flowchart.

[0048] Figure 12 This application provides an example of an application invocation flowchart.

[0049] Figure 13 This application provides an example of an application invocation flowchart.

[0050] Figure 14 This application provides an example of an application invocation flowchart.

[0051] Figure 15 A flowchart of a service governance method provided in an embodiment of this application is shown;

[0052] Figure 16 A schematic block diagram of a network node provided in an embodiment of this application is shown. Detailed Implementation

[0053] The technical solutions in the embodiments of the present invention will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments in this specification, and not all of them.

[0054] In the description of this specification, terms such as "one embodiment" or "some embodiments" mean that one or more embodiments of this specification include a particular feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0055] In this specification, unless otherwise stated, " / " signifies "or," for example, A / B can mean A or B. "And / or" in this document merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Furthermore, in the description of embodiments in this specification, "multiple" refers to two or more.

[0056] In the description of this specification, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0057] Microservice architecture is a service-oriented architecture (SOA) that breaks down complex systems into multiple smaller services or applications. These smaller services or applications are called microservices. Each microservice is responsible for implementing independent business logic. Microservices are built around business functions and can be deployed independently. Microservices depend on each other to provide a range of functionalities. Microservices are easy to understand and modify, offering flexibility in language and framework selection.

[0058] In a microservices architecture, service governance, also known as SOA governance (service-oriented architecture governance), is the process used to manage the adoption and implementation of a microservices architecture.

[0059] See Figure 1 This paper presents a service governance framework based on a software development kit (SDK). Typical applications of this framework include Spring Cloud and Dubbo. Within this framework, both the client and server components have built-in service governance functionality, typically implemented using an SDK. During the development phase of this framework, the framework's built-in SDK is used for client or server development. Generally, this framework only supports specific programming languages, such as Java. While the framework boasts high performance and ease of debugging, it cannot accommodate clients or servers using other programming languages, and its modification is difficult and requires significant intrusion. This leads to unnecessary risks and development costs.

[0060] Figure 2 This demonstrates a method for automating the deployment, scaling, and maintenance of container clusters. Containers can be used to deploy or configure microservices.

[0061] Figure 2The system shown uses Pod-level sidecars as proxies for applications or microservices, providing transparent service governance features such as link encryption, circuit breaking, rate limiting, canary releases, and distributed tracing. Unlike traditional network proxies, Istio doesn't simply perform load balancing on target IP addresses at the kernel or hardware level; instead, the sidecar handles service discovery and load balancing. The calling client only needs to access the service's virtual or logical address. The sidecar determines how to translate service metadata into an accessible network address and then routes traffic to the called microservice based on that address.

[0062] Figure 3 The system demonstrates that it can deploy Pod-level sidecars as well as Node-level sidecars.

[0063] Whether Figure 2 The system shown is still Figure 3 The system shown, while providing transparent service governance capabilities, also consumes excessive host resources (such as CPU and memory). Especially in public cloud environments, where a large number of Pods need to be deployed, the additional overhead of host resources is not negligible. During peak business periods, the sidecar and microservices may compete for resources. If the CPU load is too high, input / output (I / O) may not be processed in a timely manner, potentially leading to congestion in the sidecar and further worsening the latency of the entire chain.

[0064] This application provides a service mesh system based on microservices. (See also...) Figure 4 The service mesh system may include node 100. Node 100 may include host 110, data card 120, and network card 130.

[0065] Host 110 can be a physical machine, such as a server. Host 110 can run one or more container groups. Each container group can consist of one or more containers. For example, a container group can refer to a Pod in Kubernetes. Host 110 can deploy one or more microservices. Each microservice can be set up or run in a container group. A microservice, also known as a microservice application, can implement an independent business logic. Multiple microservices can provide corresponding business functions through call and called relationships.

[0066] Data card 120 is a hardware device with independent computing resources, such as a dedicated processor and memory. For example, data card 120 can be a software-defined infrastructure (SDI). Data card 120 can also be called an SDI data card. Data card 120 can function as a peripheral device for host 110, plugged into host 110. Data card 120 can perform service governance on access requests from host 110. For example, the sidecar corresponding to a microservice on host 110 can be deployed on data card 120, allowing data card 120 to act as a sidecar. Because the computing resources of data card 120 are independent of the computing resources of host 110, by having data card 120 act as a sidecar, the sidecar avoids preempting the computing resources of host 110 during service governance. Furthermore, the sidecar can utilize the computing resources of data card 120 locally, thereby improving the efficiency of service governance and reducing network latency.

[0067] like Figure 4 As shown, a data channel 140 is provided between the host 110 and the data card 120. The host 110 can send access requests requiring service governance to the data card 120 through the data channel 140, so that the data card 120 can perform service governance on the access requests, such as encryption and load balancing. For example, the data channel 140 can be a peripheral component interconnect express (PCIe) bus, or the data channel 140 can be carried by a PCIe bus. In one example, the data channel 140 can receive access requests sent by the host 110 based on remote direct memory access (RDMA) technology. Specifically, the host 110 can instruct the data channel 140 to directly transmit the access request to the storage area of ​​the data card 120. This enables fast data transmission between the host and the data card, further reducing network latency.

[0068] Network interface card 130 connects to network 300 to send data to and retrieve data from network 300. Network interface card 130 can communicate with host 110 and data card 120 respectively, so that network interface card 130 can send data retrieved from host 110 or data card 120 to network 300, and send data retrieved from network 300 to host 110 or data card 120. For example, network interface card 130 can be a peripheral device plugged into host 110. In one example, network interface card 130 is specifically an SDI (Surface Mount Technology) network interface card. Network interface card 130 can also be called an SDI network interface card.

[0069] In some embodiments, the network card 130 and the data card 120 can be two separate hardware cards or hardware devices. In some embodiments, the network card 130 and the data card 120 can be mounted on a single hardware card or hardware device.

[0070] In some embodiments, continue reading Figure 4 The service mesh system may also include node 200. The host 210, data card 220, network card 230 and data channel 240 included in node 200 can be implemented with reference to the above description of host 110, data card 120, network card 130 and data channel 140, respectively, and will not be repeated here.

[0071] The service mesh system can also include more nodes, each of which can be implemented with reference to node 100, and will not be described in detail here.

[0072] The foregoing has exemplarily described the structure of the service mesh system provided in the embodiments of this application. Next, in different embodiments, examples illustrate the functions of modules or components within this service mesh system.

[0073] Figure 5 A method based on is shown Figure 4 The diagram shows the application call flow of the service mesh system.

[0074] like Figure 5 As shown, host 110 can be configured with one or more container groups. Specifically, the operating system of host 110 (e.g., ...) The container group can be divided into user space and system kernel. One or more container groups can run in user space. These container groups may include container group 111 and container group 112. Container group 111 contains microservice 1111 and network interface 1112. Microservice 1111 can generate access requests to call services provided by other microservices or applications. The services provided by microservice 1111 can also be called by other microservices or applications. Microservice 1111 can send data to or receive data from the outside via network interface 1112. Container group 112 contains microservice 1121 and network interface 1122. Microservice 1121 can generate access requests to call services provided by other microservices or applications. The services provided by microservice 1121 can also be called by other microservices or applications. Microservice 1121 can send data to or receive data from the outside via network interface 1122.

[0075] Host 110 may also be configured with a regular application 113. A regular application can refer to an application outside of microservices, such as an application based on the Secure Shell Protocol (SSH) or a remote terminal protocol (telnet). Regular application 113 can call services provided by microservices or other regular applications. Services provided by regular application 113 can also be called by microservices or other regular applications. In this embodiment, a regular application can also be referred to as a regular service.

[0076] Host 110 may also be equipped with a traffic interception module 114. The traffic interception module 114 can filter out access requests that require service governance and send these requests to data card 120 via data channel 140. The traffic interception module 114 can be configured in the system kernel.

[0077] Specifically, access requests generated by microservices on host 110 may include service identifiers. These access requests are used to request the establishment of a network connection between the microservice and its target application, so that the target application can provide services to the microservice that generated the access request. The target application can be another microservice or a regular application. Typically, a service identifier can be a logical address or descriptive information; it is not the network address of a specific microservice or application, or the network address of the container group running the microservice or application. A service identifier can be used to describe or identify a service. In other words, a service identifier describes or represents the service requested by the access request. In one example, a service identifier may include a service name and / or service version number, etc. In one example, a service identifier may be pre-set information used to declare or indicate that the access request requires service governance. The traffic interception module 114 may have a governance list consisting of multiple service identifiers. For example, the traffic interception module 114 may obtain the governance list from a control plane proxy. The governance list in the control plane proxy may be obtained from the control plane. In one example, the governance list may be generated by the control plane proxy. In another example, developers or operators of a service mesh system can configure a list of systems to be governed at the control plane.

[0078] Additionally, it's understandable that for access requests requiring service governance, the target application of the request has not yet been determined before service governance is implemented. One operation of service governance is to determine the target application for the access request based on the service identifier in the access request.

[0079] Traffic interception module 114 obtains access requests from the user space of host 110 and determines whether the service identifier in the access request is in the list requiring service management. If the service identifier in the access request is in the list requiring service management, the access request is determined to be a service-manageable request and is sent to data card 120. If the service identifier in the access request is not in the management list, the access request does not require service management and can be directly sent to network 300 via network card 130, so that it can be sent to the corresponding node. For example, the service identifier in an access request may be the network address of a regular application, which is not in the list requiring service management. Network card 130 can directly send the service request to the corresponding application based on the network address.

[0080] Continue reading Figure 5 Data card 120 may include a communication proxy 121, a user-space protocol stack 122, and a control plane proxy 123. The communication proxy 121 can perform service governance on access requests, such as encryption / decryption, and determining the microservice or application providing the requested service. For example, the communication proxy 121 can be a sidecar or has sidecar functionality. More specifically, in one example, the communication proxy 121 can be a sidecar in a Kubernetes system or has sidecar functionality in a Kubernetes system.

[0081] User-mode protocol stack 122 can be used to forward access requests to communication agent 121, and to forward access requests issued by communication agent 121 to other modules or components. The specific functions of user-mode protocol 122 will be described in the specific embodiments below, and will not be repeated here.

[0082] Node 200 includes host 210, data card 220, network card 230, and data channel 240. The user space side of host 210 is configured with ordinary application 211, ordinary application 212, container group 213, and container group 214. Container group 213 is configured with special microservice 2131 and network interface 2132. Container group 214 is configured with special microservice 2141 and network interface 2142. The system kernel side of host 210 is configured with traffic interception module 215. Data card 220 may be configured with communication proxy 221, user-space protocol stack 222, control plane proxy 223, etc. The functions of each component or module in node 200 can be referred to the above description of the corresponding components or modules in node 100, and will not be repeated here.

[0083] After the service mesh system starts, its nodes can be initialized. See also... Figure 6 Taking node 100 as an example, its initialization can include the following steps.

[0084] Control plane proxy 123 can execute step 601, sending an instruction to user-space protocol stack 122 not to intercept control plane proxy inbound and outbound traffic. Here, control plane proxy 123's inbound and outbound traffic refers to data sent by and received by control plane proxy 123. This instruction includes the control plane proxy's user identity (UID). User-space protocol stack 122 can, based on the control plane proxy's user identity, not intercept traffic (or data) sent by the control plane proxy, nor intercept traffic sent to the control plane. In other words, user-space protocol stack 122 can identify the control plane proxy's inbound and outbound traffic based on the control plane proxy's user identity, thereby not intercepting the control plane proxy 123's inbound and outbound traffic, allowing the control plane proxy 123's inbound and outbound traffic to freely pass through user-space protocol stack 122.

[0085] Control plane proxy 123 can execute step 602 to receive the service list, service governance policy, and special microservice list sent by control plane 400.

[0086] Control plane 400 is the control plane in the service mesh. Control plane 400 can be called a management node. Alternatively, control plane 400 can be a program or module running on the management node that has control and management functions.

[0087] The service list may include a list of service identifiers and corresponding network addresses of microservices or applications that can provide the services corresponding to those service identifiers. A microservice can register its name, service identifier, and the network address of the container group running the microservice with the control plane 400. For example, the network address of the container group may include the IP address and port number of the container group. Therefore, the control plane 400 can obtain the service list based on the correspondence between the service identifiers of the microservices and the network addresses of the container groups running those microservices.

[0088] In some embodiments, the service list may also be referred to as a service governance strategy, or the service governance strategy may include the service list.

[0089] In some embodiments, service governance policies may include strategies such as whether to encrypt or decrypt a certain access request, or whether to perform load balancing on a certain access request. Furthermore, the specific implementation of service governance policies can be found in existing technologies, and will not be elaborated upon here.

[0090] The list of special microservices includes identification information for one or more special microservices. Generally, in a service mesh system, an access request to connect to a specific microservice requires two service governance processes: one at the sending end (e.g., node 100) and another at the receiving end (e.g., node 100). However, special microservices are different; specifically, an access request to connect to a special microservice only requires one service governance process.

[0091] Continue reading Figure 6 The control plane proxy 123 can execute step 603a, sending the governance list to the traffic interception module 114. In some embodiments, the governance list can be configured by the developers or operators of the service mesh system. In some embodiments, the control plane proxy 123 can automatically generate the governance list based on the service list. As mentioned above, the service list may include service identifiers and a list of network address mappings for microservices or applications that can provide the services corresponding to those service identifiers. The control plane proxy 123 can use the service identifiers in the service list as the governance list. It should be noted that although two methods for configuring the governance list have been introduced above, the solution provided in this application embodiment tends to adopt the method of automatically generating the governance list based on the service list in specific implementations, in order to further reduce the reliance on human intervention.

[0092] Control plane proxy 123 can execute step 603b, sending a special microservice list to user-space protocol stack 122. When user-space protocol stack 122 receives an access request, it can determine whether the microservice for which the access request requests a connection is in the special microservice list. If the microservice for which the access request requests a connection is in the special microservice list, then user-space protocol stack 122 does not send the access request to communication proxy 121, but instead sends the access request directly to host 110.

[0093] The control plane agent 123 can also perform step 603c, sending a service list and service governance policy to the communication agent 121, enabling the communication agent 121 to perform service governance on the access request based on the service list and the service governance policy. Specifically, based on the service list and using the service identifier in the access request, the target application of the access request can be determined, that is, the network address of the target application of the access request can be determined. For example, if the service governance policy includes an encryption policy, the communication agent 121 can encrypt the access request.

[0094] Control plane agent 123 can also perform step 604, receiving the updated service list, updated service governance policy, and updated special microservice list from control plane 400.

[0095] The control plane agent 123 may also perform step 605a, sending an updated list of services to be governed to the traffic interception module 114. In some embodiments, the updated list of services to be governed may be generated by the control plane agent 123 based on an updated list of services.

[0096] The control plane agent 123 can also perform step 605b, sending an updated list of special microservices to the user-space protocol stack 123.

[0097] Control plane agent 123 can also perform step 605d, sending an updated service list and an updated service governance policy to communication agent 121.

[0098] The above steps can be used to initialize node 100. The initialization of other nodes can be referenced from the initialization of node 100, and will not be repeated here.

[0099] After the nodes in the service mesh system have undergone the above initialization, the following calls can be made.

[0100] (i) Microservices on node 100 call other microservices on node 100.

[0101] (ii) Microservices on node 100 call microservices on node 200.

[0102] (III) Normal applications on node 100 call normal applications on node 200.

[0103] (iv) The microservice of node 100 calls the special microservice of node 200. The special microservice will be described in detail below and will not be repeated here.

[0104] (v) Ordinary applications on node 200 call other ordinary applications on node 200.

[0105] (vi) Node 200 forwards the access request from node 100.

[0106] (vii) Ordinary applications on node 100 call microservices on node 200.

[0107] (viii) Microservices on node 100 call ordinary applications on node 200.

[0108] Next, the eight calling scenarios described above will be explained in detail in different embodiments.

[0109] Example 1: A microservice on node 100 calls other microservices on node 100.

[0110] In this embodiment, the example of microservice 1111 calling microservice 1121 is used for illustration. Microservice 1111 can generate an access request to connect to microservice 1121, establishing a communication connection between them. This allows microservice 1121 to provide relevant services to microservice 1111, thus enabling microservice 1111 to call microservice 1121. It is understood that in a microservice architecture, when microservice 1111 generates an access request, it does not actually know that it wants to connect to microservice 1121; it only knows what kind of service it needs and includes the service identifier of that service in the access request, or in other words, as the original target address of the access request. After the communication proxy performs service governance on the access request, the target application that actually provides services to microservice 1111 can be determined, and the access request can be forwarded to the target application to establish a connection between microservice 1111 and the target application.

[0111] Next, combined Figure 7 , Figure 5 The specific data forwarding path for microservice 1111 to call microservice 1121 is explained.

[0112] Microservice 1111 can generate access request A1. Access request A1 may include the service identifier of the service provided by microservice 1121. For example, access request A1 may be a network socket connection request, where the service identifier in access request A1 can be called the original socket destination (DST) of access request A1. Microservice 1111 can execute step 701, sending access request A1 to traffic interception module 114. Traffic interception module 114 can determine whether access request A1 needs service management based on the service identifier in access request A1 and using the management list. Since the service identifier in access request A1 is the service identifier corresponding to microservice 1121, and this service identifier is located in the management list, it is determined that access request A1 needs service management. Therefore, traffic interception module 114 can execute step 702, forwarding access request A1 to data channel 140.

[0113] In an illustrative example, the data streams for steps 701 and 702 can be as follows: Figure 5As shown in (1) above. The access request A1 generated by microservice 1111 can be a network socket connection request. The service identifier in access request A1 can be used as the original socket target address for the socket connection. Access request A1 can be sent to traffic interception module 114. Traffic interception module 114 analyzes that the service corresponding to the service identifier is a service in the service mesh, that is, the service corresponding to the service identifier needs to be governed by service. Traffic interception module 114 forwards access request A1 to data channel 140.

[0114] Data channel 140 can execute step 703, sending access request A1 to user-space protocol stack 122. Step 703 can be found in [reference needed]. Figure 5 (2) In this embodiment, as described above, the data channel 140 is a PCIe bus or is carried by a PCIe bus. In step 703, the data channel 140 at one end of the host 110 can convert the access request A1 into a data stream under the PCIe protocol and transmit the converted data stream through the data channel 140. The data channel 140 at one end of the data card 120 can convert the access request A1 presented as a data stream under the PCIe protocol into a socket connection request and send the access request A1 to the user-mode protocol stack 122. In addition, in this embodiment, the user-mode protocol stack 122 is independent of the network protocol stack built into the operating system of the host 110, thereby avoiding or reducing the system overhead caused by data interaction between the host 110 and the data card 120.

[0115] User-space protocol stack 122 can execute step 704, sending access request A1 to communication proxy 121. Step 704 can be found in [reference needed]. Figure 5 (2) For example, the network state protocol stack 122 can store the service identifier in access request A1, that is, the original socket target address of access request A1. The network state protocol stack 122 can update the socket target address of access request A1 to the network address of the listening port 1 of communication proxy 121, so that access request A1 can be sent to listening port 1. At this point, a socket connection or socket link can be established between microservice 1111 and listening port 1, where listening port 1 can also be called the outbound listening port of communication proxy 121.

[0116] Communication proxy 121 can obtain access request A1 through listening port 1 and retrieve the service identifier from access request A1. It can be understood that network-state protocol stack 122 resides on the socket link between microservice 1111 and listening port 1, and stores the service identifier from access request A1. Communication proxy 121 can retrieve the service identifier from access request A1 from user-state protocol stack 122 through the socket link.

[0117] Communication proxy 121 can execute step 705 to perform service governance on access request A1. Specifically, communication proxy 121 can perform service governance according to the service identifier in access request A1 and the service governance policy. Service governance may include selecting an application that provides the service described by the service identifier to microservice 1111 through load balancing. In this embodiment, the selected application that provides the service described by the service identifier to microservice 1111 can be determined to be microservice 1121, that is, microservice 1121 is determined to be the target application of access request A1. For example, when the target application of access request A1 is determined, the socket target address of access request A1 can be updated to the network address of microservice 1121. Specifically, the network address of microservice 1121 can refer to the network address of the container group running microservice 1121, that is, the network address of container group 112. For example, the network address of container group 112 may include the IP address and port number of container group 112.

[0118] Communication proxy 121 can execute step 706, sending access request A1 to user-space protocol stack 122. User-space protocol stack 122 can execute step 707, determining that the target application of access request A1 is located on this node. Then, user-space protocol stack 122 can execute step 708, sending access request A1 to listening port 2 of communication proxy 121. See details in [link to documentation]. Figure 5 In steps (3) and (6), the user-space protocol stack 122 can determine that the user identity (UID) of the sending process of access request A1 is the executor of step 706, and can determine that the target application (i.e., microservice 1121) of access request A1 is located on this node (i.e., node 100) based on the socket target address in access request A1. Then, the user-space protocol stack 122 can determine that it received inbound traffic of access request A1 in step 706, and thus forward access request A1 to the listening port 2 of communication proxy 121. This ensures that even if a microservice calls other microservices locally, it can still achieve symmetrical entry into the communication proxy twice and perform service governance twice. Here, listening port 2 can be called the inbound listening port of communication proxy 121.

[0119] Communication agent 121 can execute step 709 to perform service management on the received access request A1 again. For example, in the service management in step 705, the business data or user data in access request A1 was encrypted. Then, in the service management in step 709, the encrypted data can be decrypted.

[0120] Communication proxy 121 can execute step 710, sending access request A1, which has undergone further service governance, to user-space protocol stack 122. Before executing step 710, communication proxy 121 can call the application programming interface (API) provided by user-space protocol stack 122 to add a service governance identifier to access request A1. This service governance identifier indicates that access request A1 has undergone two service governance processes and that the target application is located locally.

[0121] User-mode protocol stack 122 can execute step 711, sending access request A1 to data channel 140. See also... Figure 5 In steps (7) and (8), when the user-space protocol stack 122 receives the access request A1 sent in step 710, it can determine that the access request A1 is inbound traffic and that the target application is located in the container group of this node based on the service governance identifier carried by the access request A1. Therefore, step 711 can be executed to send the access request A1 to the data channel 140.

[0122] Data channel 140 can execute step 712, sending access request A1 to traffic interception module 114. See also... Figure 5 In step (8), when data channel 140, located at one end of data card 120, receives access request A1 sent in step 711, it can convert access request A1 into a data stream under the PCIe protocol and transmit the PCIe data stream towards host 110. When the PCIe data stream reaches the end of data channel 140 located at host 110, it can convert the PCIe data stream into a socket connection request.

[0123] The traffic interception module 114 is specifically an outgoing traffic interception module, meaning it only intercepts or filters traffic sent from host 110 to the outside, but does not filter traffic received by host 110 from the outside. When the traffic interception module 114 receives the access request A1 sent in step 712, it can send the access request A1 to the target application (i.e., microservice 1121) according to the socket target address of the access request A1 (i.e., the network address of microservice 1121). In this way, a socket connection can be established between microservice 1111 and microservice 1121, enabling microservice 1111 to call microservice 1121.

[0124] Example 2: A microservice on node 100 calls a microservice on node 200.

[0125] In this embodiment, the example of microservice 1111 calling microservice 2141 is used for explanation. Microservice 1111 can generate an access request to connect to microservice 2141, establishing a communication connection between them. This allows microservice 2141 to provide relevant services to microservice 1111, thus enabling microservice 1111 to call microservice 2141. It is understood that in a microservice architecture, when microservice 1111 generates an access request, it does not actually know that it wants to connect to microservice 2141; it only knows what service is needed and includes that service in the access request, or as the original target address of the access request. After the communication proxy performs service governance on the access request, the target application that actually provides services to microservice 1111 can be determined, and the access request is forwarded to the target application to establish a connection between microservice 1111 and the target application.

[0126] Next, combined Figure 8 , Figure 5 The specific data forwarding path for microservice 1111 to call microservice 2141 is explained.

[0127] Microservice 1111 can generate access request A2. Access request A2 may include the service identifier of the service provided by microservice 2141. Microservice 1111 can execute step 801, sending access request A2 to traffic interception module 114. Traffic interception module 114 can determine whether access request A2 requires service management based on the service identifier in access request A2 and using the management list. The service identifier in access request A2 is the service identifier corresponding to microservice 2141, and this service identifier is located in the management list, confirming that access request A2 requires service management. Therefore, traffic interception module 114 can execute step 802, forwarding access request A2 to data channel 140.

[0128] Data channel 140 can execute step 803, sending access request A2 to user-space protocol stack 122.

[0129] User-space protocol stack 122 can execute step 804, sending access request A2 to communication agent 121.

[0130] The specific execution of steps 801, 802, 803, and 804 can be referred to the above description of steps 701, 702, 703, and 704, and will not be repeated here.

[0131] Communication proxy 121 can execute step 805 to perform service governance on access request A2. Specifically, communication proxy 121 can perform service governance according to the service identifier in access request A2 and the service governance strategy. Service governance may include selecting an application that provides the service described by the service identifier for microservice 1111 through load balancing. In this embodiment, the selected application that provides the service described by the service identifier for microservice 1111 can be determined to be microservice 2141, that is, microservice 2141 is determined to be the target application of access request A2. For example, when microservice 2141 is determined to be the target application of access request A2, the socket target address of access request A2 can be updated to the network address of microservice 2141. Specific microservice 2131 can be referred to as the target application of access request A4, and the network address of specific microservice 2131 can be referred to as the target application address of access request A4. Specifically, the network address of microservice 2141 can refer to the network address of the container group running microservice 2141, that is, the network address of container group 214. For example, the network address of container group 214 may include the IP address and port number of container group 214.

[0132] Communication proxy 121 can execute step 806, sending access request A2 to user-space protocol stack 122. User-space protocol stack 122 can execute step 807, determining that the actual target application of access request A2 is not located on this node. Then, user-space protocol stack 122 can execute step 808, adding a service mesh identifier to access request A2. The service mesh identifier is used to indicate that the target application of access request A2 belongs to a microservice. The specific form of the service mesh identifier can be a custom field, number, etc. In a specific form, the developers or operators of the service mesh system can customize the service mesh identifier. User-space protocol stack 122 can also execute step 809, encapsulating the target application address of access request A2. As mentioned above, the target application address determined in step 805 is the network address of microservice 2141. It can be understood that microservice 2141 is located on a certain node (i.e., node 200). In step 809, the network address of microservice 2141 can be encapsulated as the IP address of that node. For example, the network address of microservice 2141 can be the network address of container group 214. The network address of container group 214 may include the IP address and port number of container group 214. If container 214 is located on node 200, then in step 809, the network address of microservice 2141 is encapsulated as the IP address of node 200.

[0133] In addition, the execution of steps 806, 807, 808, and 809 can also refer to Figure 5(3) Specifically, in step 806, access request A2, as outgoing traffic sent by communication proxy 121, is sent to user-space protocol stack 122. User-space protocol stack 122 can determine that communication proxy 121 is the sender of the outgoing traffic based on the data stream sending process UID of access request A2, and determine that the target application is not located on this node (node ​​100) based on the target application address of access request A2. Then, service mesh identifiers can be added to access request A2, target application address encapsulation, etc.

[0134] Next, the user-space protocol stack 122 can execute step 810, sending access request A2 to the network interface card 130. (See also...) Figure 5 In (4), when the network interface card (NIC) processes traffic destined for the outside world, it can directly send the data to the NIC of the target node via the network. Returning to this embodiment, refer to... Figure 8 Network interface card 130 can execute step 811, sending access request A2 to network interface card 230. Specifically, network interface card 130 can send access request A2 to network interface card 230 via network 300.

[0135] See Figure 8 Network interface card 230 can perform step 812 to recover the target application address from access request A2; and perform step 813 to determine that access request A2 has a service mesh identifier. See also... Figure 5 In (10), after receiving the data packet carrying access request A2, the physical network card of network card 230 can recover the target application address of access request A2 and determine whether access request A2 has a service mesh identifier.

[0136] Next, network interface card 230 can execute step 814, sending access request A2 to user-space protocol stack 222. See also... Figure 5 In (12), the network card 230 forwards the access request A2 to the user-mode protocol stack 222 through the virtual network port between it and the data card 220.

[0137] User-space protocol stack 222 can execute step 815 to determine that the target application of access request A2 is not a special microservice. As mentioned above, during the initialization process, the user-space protocol stack can obtain a list of special microservices. The list of special microservices includes identification information for one or more special microservices. The identification information can be a network address. Therefore, in step 815, user-space protocol stack 222 can determine that the target application is not a special microservice based on its network address, i.e., it determines that the network address of the target application is not in the list of special microservices. After determining that the target application of access request A2 is not a special microservice, user-space protocol stack 222 can execute step 816 to send access request A2 to communication proxy 221. Communication proxy 221 can perform secondary service governance on access request A2. For example, it can decrypt the business data in access request A2. Afterwards, communication proxy 221 can execute step 818 to send access request A2 after secondary service governance to user-space protocol stack 222. Before executing step 818, communication agent 221 can call the API provided by user-space protocol stack 222 to add a service governance identifier to access request A2. This service governance identifier indicates that access request A2 has undergone service governance and that the target application is located locally (on the node where communication agent 221 is located).

[0138] For further instructions on steps 815-818, please refer to [link / reference needed]. Figure 5 In step (14), the user-space protocol stack 222 determines that the target application address of access request A2 is not the address of a non-special microservice, i.e., the target application is not a special microservice. Therefore, it forwards access request A2 to the listening port 3 of the communication proxy 221. Listening port 3 is the inbound traffic listening port of the communication proxy 221. The communication proxy 221 records that access request A2 is inbound traffic and performs service management on access request A2. After performing service management on access request A2, and when sending access request A2 to upstream modules or components, the API of the user-space protocol stack 222 can be called to add a service management identifier to access request A2.

[0139] User-mode protocol stack 222 can execute step 819, sending access request A2 to data channel 240. (See also...) Figure 5 In step (15), when the user-space protocol stack 222 receives the access request A2 sent in step 818, it can determine that the access request A2 is inbound traffic and that the target application is located in the container group of this node based on the service governance identifier carried by the access request A2. Therefore, step 819 can be executed to send the access request A2 to the data channel 240.

[0140] Data channel 240 can execute step 820, sending access request A2 to traffic interception module 215. See also... Figure 5In step (15), when data channel 240, located at one end of data card 120, receives access request A2 sent in step 819, it can convert access request A2 into a data stream under the PCIe protocol and transmit the PCIe data stream towards host 210. When the PCIe data stream reaches the end of data channel 240 located at host 210, it can convert the PCIe data stream into a socket connection request.

[0141] The traffic interception module 215 is specifically an outgoing traffic interception module, meaning it only intercepts or filters traffic sent from host 210 to the outside, but does not filter traffic received by host 210 from the outside. When the traffic interception module 215 receives the access request A2 sent in step 820, it can execute step 821 to send the access request A2 to the microservice application 2141. Specifically, it can send the access request A2 to the target application (i.e., microservice 2141) according to the socket target address of the access request A2 (i.e., the network address of microservice 2141).

[0142] Therefore, a connection can be established between microservice 1111 and microservice 2141, enabling microservice 1111 to call microservice 2141. For example, access request A2 can specifically be a socket connection request, and the established connection between microservice 1111 and microservice 2141 can be a socket connection.

[0143] Example 3: A regular application on node 100 calls a regular application on node 200.

[0144] Next, combined Figure 9 , Figure 5 Taking the example of ordinary application 113 calling ordinary application 211, this embodiment introduces the solution provided.

[0145] Ordinary application 113 can generate access request A3, where the target application address of access request A3 is the network address of ordinary application 211. For example, the network address of ordinary application 211 may include its IP address and port number. See also... Figure 9 Ordinary application 113 can execute step 901, sending access request A3 to traffic interception module 114. Traffic interception module 114 can determine that the network address of the ordinary application is not in the list of applications requiring management, and then can execute step 902, sending access request A3 to the virtual network interface of host 110, so that the virtual network interface of host 110 can execute step 903, sending access request A3 to network card 130. See also... Figure 5In (9), ordinary application 113 can send access request A3. Traffic interception module 114 determines that the target application of access request A3 is an ordinary application and directly sends the access request to network card 130 through virtual network port.

[0146] Network interface card 130 can execute step 904, encapsulating the target application address of access request A3. Specifically, it can be done as follows: Figure 5 As shown in (5), when network interface card 130 detects that the target application of access request A3 is located on a node other than node 100, it can encapsulate the address of the target application. The target application address can be encapsulated as the address of the node where the target application resides. For example, if the target application address is the network address of ordinary application 211, and the ordinary application is located on node 200, this network address can be encapsulated as the IP address of node 200. For example, the network address of ordinary application 211 can include the IP address and port number of ordinary application 211.

[0147] Network interface card 130 can also perform step 905, sending access request A3 to network interface card 230. For details, please refer to... Figure 5 In step (5), network card 130 can send access request A3 to network 300 through physical network card. Then, network 300 can forward access request A3 to network card 230 according to the destination address of access request A3 (i.e. the address obtained after encapsulation in step 904).

[0148] After receiving access request A3, network interface card 230 can execute step 906 to restore the target application address of access request A3. That is, in step 906, the target application address encapsulated in step 904 can be restored.

[0149] Network interface card 230 can execute step 907 to determine that access request A3 does not have a service mesh identifier. It can be understood that service request A3 did not pass through data card 120, therefore, it does not have a service mesh identifier. Network interface card 230 can also execute step 908 to determine that the target application address is not a service mesh gateway address. A service mesh gateway address refers to the address of a listening port of a communication proxy. For example, Figure 5 Listening port 3 in the network interface can be used as the service mesh gateway address of node 200. Then, network interface card 230 can execute step 909, sending access request A3 to the virtual network interface of host 210. The virtual network interface of host 210 can execute step 910, sending access request A3 to traffic interception module 215. Traffic interception module 215 can execute step 911, sending access request A3 to ordinary application 211.

[0150] For further instructions on steps 907-911, please refer to [link / reference needed]. Figure 5In step (11), if network interface card 230 determines that access request A3 does not have a service mesh identifier and the target application address is not a service mesh gateway, then access request A3 can be forwarded to host 210 through the virtual network interface. Then, the system kernel of host 210 can directly send access request A3 to ordinary application 211.

[0151] Therefore, a connection can be established between ordinary application 113 and ordinary application 211, enabling ordinary application 113 to call ordinary application 211. For example, access request A3 can specifically be a socket connection request, and the established connection between ordinary application 113 and ordinary application 211 can be a socket connection.

[0152] Example 4: A microservice on node 100 calls a special microservice on node 200.

[0153] Specialized microservices generally include, but are not limited to, applications that can be connected without a second communication proxy (such as a sidecar). In other words, access requests to a specialized microservice can reach the target application without undergoing secondary service governance, thus establishing a connection between the source and target applications. The source application is the application that generates the access request. Typical specialized microservices include those providing rate limiting services and those providing data collection services.

[0154] One scenario for invoking a special microservice is when an access request initiated by a microservice in the host user space passes through a communication proxy for the first time. The communication proxy itself needs to actively invoke the special microservice to perform service governance on the access request. For example, it can invoke a microservice that provides rate limiting and determine whether the access request exceeds the rate limiting threshold. If it exceeds the threshold, the communication proxy can return a failure response to the microservice that initiated the access request. During the first passage of the access request through the communication proxy, the proxy can also invoke a data collection service to report statistical link call data for network call topology mapping.

[0155] Since special microservices are microservices within the service mesh, it is difficult to configure an interception scheme in the network interface card (NIC) to block access requests from applications targeting special microservices. This can lead to access requests that have already undergone the first service governance process being sent again to a second communication proxy, resulting in unnecessary service governance. To address this issue, this embodiment can determine whether the target application of an access request is a special microservice by using a list of special microservices in the user-space protocol. Therefore, if the target application is not a special microservice, the access request can be sent directly to the host without going through a second communication proxy.

[0156] Next, combined Figure 10 , Figure 5Taking the example of microservice 1111 on node 100 calling special microservice 2131 on node 200, the solution of this embodiment is illustrated.

[0157] Microservice 1111 can generate access request A4. Access request A4 may include the service identifier of the service provided by special microservice 2131. Microservice 1111 can execute step 1001, sending access request A4 to traffic interception module 114. Traffic interception module 114 can determine whether access request A4 requires service management based on the service identifier in access request A4 and using the management list. The service identifier in access request A4 is the service identifier corresponding to special microservice 2131, and this service identifier is located in the management list, confirming that access request A4 requires service management. Therefore, traffic interception module 114 can execute step 1002, forwarding access request A4 to data channel 140.

[0158] Data channel 140 can execute step 1003, sending access request A4 to user-space protocol stack 122.

[0159] User-space protocol stack 122 can execute step 1004, sending access request A4 to communication agent 121.

[0160] The specific execution of steps 1001, 1002, 1003, and 1004 can be found in the description of steps 701, 702, 703, and 704 above, and will not be repeated here.

[0161] Communication proxy 121 can execute step 1005 to perform service governance on access request A4. Specifically, communication proxy 121 can perform service governance according to the service identifier in access request A4 and the service governance strategy. Service governance may include selecting an application that provides the service described by the service identifier to microservice 1111 through load balancing. In this embodiment, the selected application that provides the service described by the service identifier to microservice 1111 can be determined to be a special microservice 2131, that is, the special microservice 2131 is determined to be the target application of access request A4. For example, when the special microservice 2131 is determined to be the target application of access request A4, the socket target address of access request A4 can be updated to the network address of special microservice 2131. Here, special microservice 2131 can be referred to as the target application of access request A4, and the network address of special microservice 2131 can be referred to as the target application address of access request A4. The network address of special microservice 2131 can refer to the network address of the container group running special microservice 2131, that is, the network address of container group 213. For example, the network address of container group 213 may include the IP address and port number of container group 213.

[0162] Communication proxy 121 can execute step 1006, sending access request A4 to user-space protocol stack 122. User-space protocol stack 122 can execute step 1007, determining that the target application of access request A4 is not located on this node. Then, user-space protocol stack 122 can execute step 1008, adding a service mesh identifier to access request A4. The service mesh identifier can be found in the above description. Figure 8 The description of the illustrated embodiment will not be repeated here. The user-space protocol stack 122 can also execute step 1009, encapsulating the target application address of access request A4. As described above, the target application address determined in step 1005 is the network address of the special microservice 2131. It can be understood that the special microservice 2131 is located on a certain node (i.e., node 200). In step 1009, the network address of the special microservice 2131 can be encapsulated as the address of that node. For example, the network address of the special microservice 2131 can be the network address of container group 213. Container group 213 is located on node 200, and in step 1009, the network address of the special microservice 2131 can be encapsulated as the IP address of node 200.

[0163] In addition, the execution of steps 1006, 1007, 1008, and 1009 can also refer to Figure 5 (3) Specifically, in step 1006, access request A4, as outgoing traffic issued by communication proxy 121, is sent to user-space protocol stack 122. User-space protocol stack 122 can determine that communication proxy 121 is the sender of the outgoing traffic based on the data stream sending process UID of access request A4, and determine that the target application is not located on this node (node ​​100) based on the target application address of access request A4. Then, service mesh identifiers can be added to access request A4, target application address encapsulation, etc.

[0164] Next, the user-space protocol stack 122 can execute step 1010, sending access request A4 to the network interface card 130. See also... Figure 5 In (4), when the network interface card (NIC) processes traffic destined for the outside world, it can directly send the data to the NIC of the target node via the network. Returning to this embodiment, refer to... Figure 10 Network interface card 130 can execute step 1011, sending access request A4 to network interface card 230. Specifically, network interface card 130 can send access request A4 to network interface card 230 via network 300.

[0165] See Figure 10 Network interface card 230 can perform step 1012 to recover the target application address from access request A4; and perform step 1013 to determine that access request A4 has a service mesh identifier. See also... Figure 5In (10), after receiving the data packet carrying access request A4, the physical network card of network card 230 can recover the target application address of access request A4 and determine whether access request A4 has a service mesh identifier.

[0166] Next, network interface card 230 can execute step 1014, sending access request A4 to user-space protocol stack 222. See also... Figure 5 In (12), the network card 230 forwards the access request A4 to the user-mode protocol stack 222 through the virtual network port between it and the data card 220.

[0167] User-space protocol stack 222 can execute step 1015 to determine that the target application of access request A4 is a special microservice. As described above, during the initialization process, the user-space protocol stack can obtain a list of special microservices. The list of special microservices includes identification information for one or more special microservices. The identification information can be a network address. Therefore, in step 1015, user-space protocol stack 222 can determine that the target application is a special microservice based on its network address, that is, determine that the network address of the target application is located in the list of special microservices.

[0168] After determining that the target application of access request A4 is a specific microservice, user-space protocol stack 222 can execute step 1016, sending access request A4 to data channel 240. Data channel 240 can execute step 1017, sending access request A4 to traffic interception module 215. Traffic interception module 215 can execute step 1018, sending access request A4 to specific microservice 2131.

[0169] The execution of steps 1016-1018 can be referred to Figure 5 In (13), after determining that the target application of access request A4 is special microservice 2131, user-space protocol stack 222 can directly send access request A4 to data channel 240. When access request A4 is a socket connection request, when data channel 240 is located at one end of data card 120 and receives access request A4, it can convert access request A4 into a data stream under the PCIe protocol and transmit the PCIe data stream towards host 210. When the PCIe data stream reaches the end of data channel 240 located at host 210, it can be converted into access request A4 in the form of a socket connection request. The system kernel of host 210 can then directly send access request A4 to special microservice 2131.

[0170] Therefore, a connection can be established between microservice 1111 and special microservice 2131, enabling microservice 1111 to call special microservice 2131. For example, access request A4 can specifically be a socket connection request, and the established connection between microservice 1111 and special microservice 2131 can be a socket connection.

[0171] Example 5: A regular application on node 200 calls another regular application on node 200.

[0172] Next, combined Figure 11 , Figure 5 Taking the example of ordinary application 212 calling ordinary application 211, this embodiment introduces the solution provided.

[0173] See Figure 11 Ordinary application 212 can generate access request A5, where the target application address of access request A5 is the network address of ordinary application 211. Ordinary application 212 can execute step 1101, sending access request A5 to traffic interception module 215. Traffic interception module 215 can determine that the target application of access request A5 is ordinary application 211. Traffic interception module 215 can execute step 1102, sending access request A5 to ordinary application 211.

[0174] Please refer to Figure 5 In (17a), the target application of the access request initiated by ordinary application 212 is ordinary application 211. The traffic interception module 215 in the system kernel of host 210 can determine that the target application of the connection request initiated by ordinary application 212 is ordinary application 211 on the local machine, and can then directly send the access request initiated by ordinary application 212 to ordinary application 211.

[0175] Therefore, a connection can be established between ordinary application 212 and ordinary application 211, enabling ordinary application 212 to call ordinary application 211.

[0176] Example 6: Node 200 forwards the access request from Node 100.

[0177] The service mesh system may also include node 500. Due to network limitations, there is no direct communication connection between node 100 and node 500, making it difficult for access requests from microservices on node 100 to be directly sent to node 500. In this case, when a microservice on node 100 needs to call an application (which can be a microservice or a regular application) on node 500, node 200 can forward the access request sent by node 100 to node 500. In other words, node 200 can provide a relay service, acting as a relay node between node 100 and node 500. This relay service is a service within the service mesh, meaning it can be provided by one or more microservices. In one example, the relay service could be provided by a communication proxy within a node.

[0178] Next, combined Figure 12 , Figure 5 Taking microservice 1111 calling services on node 500 as an example, the solution provided in this embodiment will be explained.

[0179] Microservice 1111 can generate access request A6 to request the application on node 500. For ease of description, the application on node 500 requested by access request A6 can be referred to as application B. In the absence of a direct communication connection between node 100 and node 500, for access request A6 as a socket connection request, microservice 1111 can encapsulate the network address of application B in the C1 layer header of access request A6, and use the service identifier of the relay service as the target address of access request A6 in the C2 layer. The target address in the C2 layer is the direct address of access request A6. Modules or components along the forwarding path of access request A6 can directly identify the target address in the C2 layer and route access request A6 based on this target address. It can be understood that in a service mesh system, the target address set by microservice 1111 for the access request in the C2 layer is a service identifier, not the address of a specific module or component. It is used to indicate that the access request requires service governance, thus allowing the access request to be forwarded to the communication broker based on the target address in the C2 layer. For example, layer C2 can be the transport layer or layer 4 in a seven-layer network protocol. Layer C1 is a higher layer than layer C2; for example, layer C1 can be the application layer or layer 7 in a seven-layer network protocol.

[0180] Microservice 1111 can execute step 1201, sending access request A6 to traffic interception module 114. Traffic interception module 114 can determine the target address of the transport layer of access request A6, which is the service identifier of the relay service, and it is located in the list of services to be governed, thus determining that access request A6 needs to be governed by services.

[0181] Traffic interception module 114 can execute step 1202, forwarding access request A6 to data channel 140. Data channel 140 can execute step 1203, sending access request A6 to user-space protocol stack 122. User-space protocol stack 122 can execute step 1204, sending access request A6 to communication proxy 121.

[0182] The specific execution of steps 1202, 1203, and 1204 can be found in the descriptions of steps 701, 702, 703, and 704 above, as well as the descriptions of steps 701, 702, 703, and 704 above. Figure 5 The introductions to (1) and (2) are omitted here.

[0183] Communication proxy 121 can execute step 1205 to perform service governance on access request A6. Specifically, communication proxy 121 can perform service governance according to the service identifier of the C1 layer of access request A6 and the service governance policy to determine the application that provides relay service for access request A6. For example, in step 1205, communication proxy 221 in node 200 can be determined to provide relay service for access request A6. That is, communication proxy 221 is determined to be the target application of access request A6, and the network address of communication proxy 221 is the target application address of access request A6. Afterwards, communication proxy 121 can update the target address of the C2 layer of access request A6 to the network address of communication proxy 221. For example, the network address of communication proxy 221 can be the network address of listening port 3. Communication proxy 121 can send the updated access request A6 to user-space protocol stack 122 in step 1206.

[0184] User-space protocol stack 122 can execute step 1207 to determine that the target application of access request A6 is not located on this node. User-space protocol stack 122 can execute step 1208 to add a service mesh identifier to access request A6, and execute step 1209 to encapsulate the target application address of access request A6. Specifically, the network address of communication proxy 221 can be encapsulated into the IP address of node 200. User-space protocol stack 122 can also execute step 1210 to send the address-encapsulated access request A6 to network interface 130. Network interface 130 can execute step 1211 to send access request A6 to network card 230.

[0185] Network interface card 230 can execute step 1212 to restore the target application address of access request A6; and execute step 1213 to determine that access request A6 has a service mesh identifier. Then, network interface card 230 can execute step 1214 to send access request A6 to user-space protocol stack 222.

[0186] User-space protocol stack 222 can execute step 1215 to determine that the target application of access request A6 is not a special microservice. Afterwards, user-space protocol stack 222 can send access request A6 to communication proxy 221 through step 1216.

[0187] For details on the execution of steps 1205-1216, please refer to the above text. Figure 8 Steps 805-816, and Figure 5 The implementation of (2), (3), (4), (10), (12), and (14) will not be repeated here.

[0188] Continue reading Figure 12 Communication proxy 221 can execute step 1217, parsing the C1 layer header of access request A6 to obtain the network address of application B. Communication proxy 221 can skip service governance of access request A6 and instead execute step 1218, updating the target application address of access request A6 to the network address of application B; that is, updating the target application of access request A6 to application B. Then, it can execute step 1220, sending the updated access request A6 to user-space protocol stack 222. For example, in step 1220, communication proxy 221 can call the API of user-space protocol stack 222 to add a service governance identifier to access request A6.

[0189] For details on the execution of steps 1217-1220, please refer to [link / reference needed]. Figure 5 In (15), the communication proxy 221 can record that access request A6 is inbound traffic, and determine that node 200 is the relay node of access request A6 based on the content of the data packet of access request A6 (i.e., the content of C1 layer). Thus, subsequent service governance is skipped; the target application address of access request A6 is updated to the address of application B; and based on the fact that access request A6 is inbound traffic, the API of user-space protocol stack 222 is called to add a service governance identifier to access request A6.

[0190] User-space protocol stack 222 can execute step 1221, determining that the target application of access request A6 is not located on this node (node ​​200); and execute step 1222, encapsulating the target application address of access request A6. For example, the network address of application B can be encapsulated as the IP address of node 500. In one example, if application B is a microservice, user-space protocol stack 222 can also add a service mesh identifier to access request A6. Then, in step 1223, user-space protocol stack 222 can send access request A6 to network interface card 230. Network interface card 230 can execute step 1224, sending access request A6 to node 500.

[0191] For details on the execution of steps 1221-1224, please refer to [link / reference needed]. Figure 5 In step (16), the user-space protocol stack 222 can determine that the target application of access request A6 is not located on this node, and based on the service governance identifier of access request A6, determine that access request A6 is inbound traffic. Then, a service mesh identifier can be added to access request A6, the target application address can be encapsulated, and then access request A6 can be sent to network 300 through network card 230, so that access request A6 can be sent to node 500 through network 300.

[0192] The above scheme allows for indirect communication between nodes by using other nodes as relay nodes, even when there is no direct communication connection between the node and another node.

[0193] Example 7: A regular application on node 100 calls a microservice on node 200.

[0194] In scenarios where ordinary applications need to call microservices, this can be achieved by configuring the communication proxy as an inbound gateway. The inbound gateway can also be called a service mesh gateway. When the target address of an access request is the service mesh gateway address, even if the access request does not include a service mesh identifier, the network interface card (NIC) can still send the access request to the data card. The data card then performs service governance on the access request and sends it to the corresponding microservice, enabling the ordinary application to call the microservice.

[0195] Next, combined Figure 13 , Figure 5 Taking the ordinary application 113 calling the microservice 2141 as an example, this embodiment provides an example of the scheme for ordinary applications to call microservices.

[0196] Ordinary application 113 can generate an access request A7 with the service mesh gateway address of node 200 as the initial destination address. Furthermore, service request A7 may also include the service identifier of the service required by ordinary application 113. The service identifier can be referred to the above description and will not be repeated here. For example, access request A7 can be a data packet, and the service identifier can be encapsulated in the application layer header of the data packet. Additionally, it can be understood that the destination address of access request A7 is generally located at the transport layer.

[0197] Normal application 113 can execute step 1301, sending access request A7 to network card 130. See also... Figure 5In step (5), when access request A7 passes through traffic interception module 114, traffic interception module 114 determines that its initial destination address is not in the list of addresses to be managed. For example, its initial destination address can be an address located at the transport layer. That is, traffic interception module 114 determines that the transport layer address of access request A7 is not in the list of addresses to be managed. Therefore, traffic interception module 114 can send access request A7 to network card 130 through virtual network interface.

[0198] Network interface card 130 can perform step 1302, encapsulating the initial destination address of access request A7. For example, the service mesh gateway address used as the initial destination address can be the network address of a listening port of communication proxy 221. This listening port's network address can be encapsulated into the IP address of node 200.

[0199] Network interface card 130 can execute step 1303, sending the access request A7, after initial target address encapsulation, to network interface card 230. See details... Figure 5 In step 1303, access request A7 can enter network 300 through the physical network card of network card 130, and after being forwarded by network 300, it can be received by the physical network card of network card 230.

[0200] Network interface card 230 can execute step 1304 to restore the initial destination address of access request A7, that is, to restore the service mesh gateway address. Network interface card 230 can then execute step 1305 to send access request A7 to user-space protocol stack 222. (See also...) Figure 5 In (17b) and (12), the network interface card 230 can determine that the initial destination address of the access request A7 is the service mesh gateway address. When the initial destination address of the access request A7 is the service mesh gateway address, even if the access request A7 does not have a service mesh identifier, the network interface card 230 can still send the access request A7 to the user-space protocol stack 222 through the virtual network port.

[0201] User-space protocol stack 222 can execute step 1306 to determine that the initial destination address of access request A7 is the service mesh gateway address. Then, it can execute step 1307 to send access request A7 to communication proxy 221. See [reference needed] for an example. Figure 5 In (14), the initial target address can be set to the network address of the listening port 3 of the communication agent 221. If the user-space protocol stack 221 determines that the initial target address is not the address of a special microservice and that the access request A7 does not have a service mesh identifier, it can send the access request A7 to the listening port 3 of the communication agent 221.

[0202] Communication proxy 221 can execute step 1308 to determine the service actually requested by access request A7. As mentioned above, access request A7 carries a service identifier, which is used to represent the service required by ordinary application 113. This service identifier can be in the application layer header of access request A7. Communication proxy 221 can parse access request A7, for example, it can parse the application layer header of access request A7 to obtain the service identifier. After obtaining the service identifier, communication proxy 221 can execute step 1309 to perform service governance on access request A7. Specifically, based on the service identifier, using the service list and service governance strategy, the microservice used to provide the service represented by the service identifier can be determined. In this embodiment, microservice 2141 can be set to provide the service represented by the service identifier. Then, communication proxy 211 can execute step 1310 to send access request A7 to user-space protocol stack 222. The execution of steps 1308-1310 can be found in [reference needed]. Figure 5 In section (14), when communication agent 221 receives access request A7 through listening port 3, it can record access request A7 as inbound traffic. After performing service governance on access request A7, when sending access request A7 to upstream modules or components, it can call the API of user-space protocol stack 222 to add a service governance identifier to access request A7.

[0203] In this embodiment, the service identifier of a certain service can be simply referred to as the identifier of the service.

[0204] User-space protocol stack 222 can execute step 1311, sending access request A7 to microservice 2141. The specific process of step 1311 can be found in the above description. Figure 8 The details of steps 819-821 will not be repeated here.

[0205] Therefore, a connection can be established between the ordinary application 113 and the microservice 2141, enabling the ordinary application 113 to call the microservice 2141. For example, the access request A7 can specifically be a socket connection request, and the established connection between the ordinary application 113 and the microservice 2141 can be a socket connection.

[0206] Example 8: A microservice on node 100 calls a regular application on node 200.

[0207] In a service mesh system, certain general applications may be invoked by microservices. In this embodiment, to enable these general applications to be invoked by microservices, service identifiers for the services provided by these general applications can be predefined. Taking service C as an example, its service identifier can be information describing or representing service C. Service C can be provided by a general application. The service identifiers of the services provided by these general applications can be set in the governance list. In this embodiment, for ease of description, the service identifiers of the services provided by general applications can be referred to as the service identifiers of general applications. For example, the service identifier of a general application can be its network address. In one example, the network address of a general application may include its IP address and port number.

[0208] As described above, the governance list can be pre-configured by the service mesh system developers or operations personnel. When configuring the governance list, service identifiers of common applications that may be called by microservices can be added to the list. When the governance list includes the service identifiers of common applications, access requests carrying these service identifiers can be sent to the data card to accept service governance from the communication proxy. Thus, the service identifiers of common applications are used to declare that access requests require service governance.

[0209] In some embodiments, the service list may also include a mapping between service identifiers and network addresses for regular applications, so that the communication agent can determine the accessible network address based on the service identifier. The service list includes the type of application corresponding to the network address; the application type can be categorized as a microservice or a regular application. That is, the service list records whether the application corresponding to the network address is a microservice or a regular application.

[0210] For specific configuration methods of the governance list and service list, please refer to the above text. Figure 6 The embodiments shown will not be described in detail here.

[0211] Next, combined Figure 14 , Figure 5 Taking microservice 1111 calling ordinary application 211 as an example, this embodiment provides an example of the scheme for microservice calling ordinary application.

[0212] When microservice 1111 needs to use the services provided by ordinary application 211, it can generate access request A8 and use the service identifier of the service as the initial target address of access request A8.

[0213] Microservice 1111 can execute step 1401, sending access request A8 to traffic interception module 114. Traffic interception module 114 can determine that the initial target address of access request A8, or the service identifier carried by access request A8, is in the list of services to be managed. Traffic interception module 114 can then execute step 1402, sending access request A8 to data channel 140. Data channel 140 can then execute step 1403, sending access request A8 to user-space protocol stack 122. User-space protocol stack 122 can then execute step 1404, sending access request A8 to communication proxy 121. The execution of steps 1401-1404 can be referenced above. Figure 7 Steps 702-704, and Figure 5 The introductions of (1) and (2) will not be repeated here.

[0214] Communication agent 121 can perform step 1405 to perform service governance on access request A8. This may include determining, based on the service identifier carried in access request A8 and using a service list according to a load balancing strategy, an application that can provide the service described by the service identifier. The determined application may be designated as ordinary application 211. After step 1405, the network address of ordinary application 211 is determined as the target application address of access request A8, and correspondingly, ordinary application 211 is determined as the target application of access request A8.

[0215] Communication proxy 121 can perform step 1406, adding a non-service mesh identifier to access request A8. The non-service mesh identifier indicates that the target application carrying the access request does not belong to a microservice. As mentioned above, the service list records the type of application corresponding to the network address. When it is determined that the network address of ordinary application 211 is the target application address of access request A8, it can be determined that the target application of access request A8 is a general application, not a microservice in a service mesh. Therefore, a non-service mesh identifier can be added to access request A8. For example, communication proxy 121 can call an API to add a non-service mesh identifier to access request A8.

[0216] After executing step 1406, the communication agent 121 can execute step 1407 to send access request A8 to the user-space protocol stack 122.

[0217] User-space protocol stack 122 can execute step 1408 to determine that the target application of access request A8 is not located on this node, and to determine that access request A8 has a non-service mesh identifier. Then, user-space protocol stack 122 can execute step 1409 to encapsulate the target application address of access request A8. Specifically, the target application address of access request A8 can be encapsulated into the IP address of node 200.

[0218] Next, the user-space protocol stack 122 can send access request A8 to network interface card 130. When network interface card 130 receives access request A8, it can execute step 1411 to send access request A8 to network interface card 230.

[0219] When network interface card 230 receives access request A8, it can execute step 1412 to restore the target application address of access request A8. It can also execute steps 1413 and 1414. In step 1413, it can be determined that access request A8 does not have a service mesh identifier, and that access request A8 has a non-service mesh identifier. In step 1414, it is determined that the target application address of access request A8 is not a service mesh gateway address. Therefore, network interface card 230 can execute step 1415 to directly send access request A8 to ordinary application 211.

[0220] You can also refer to Figure 5 In (11), when A8 does not have a service mesh identifier and the target application address of access request A8 is not the service mesh gateway address, the network card 230 no longer sends access request A8 to the data card 220, but directly sends access request A8 to the host 210 through the virtual network card, so that the host 210 can send access request A8 directly to the ordinary application 211.

[0221] Thus, a connection is established between microservice 1111 and ordinary application 211, enabling microservice 1111 to call ordinary application 211. For example, access request A8 can specifically be a socket connection request, and the established connection between microservice 1111 and ordinary application 211 can be a socket connection.

[0222] As described above, in this embodiment, the sidecar can be moved down to the data card, allowing service calls within the service mesh to be processed and sent from the data card, thus eliminating the need to consume host computing resources, improving service governance efficiency, and saving host computing resources. Furthermore, customer applications can be applied to the service mesh system provided in this embodiment without modification, thus giving the service mesh system significant utilization value.

[0223] In addition to the above embodiments, this application also provides a service mesh system. (This system can be used to participate in...) Figure 4 The service system may include node 100, node 100 includes host 110 and data card 120, data card 120 is inserted into host 110, data card 120 and host 110 are connected by a data channel 140, host 110 runs a first container group, the first container group is configured with a first microservice, and data card 120 is connected to network 300.

[0224] Data card 120 can receive service governance policies sent by the management node via network 300, and perform service governance on the first access request sent by host 110 to data card 120 via data channel 140 according to the service governance policies. The first access request is an access request from host 110 to the second microservice from the first container group's first microservice. For details, please refer to the above text. Figure 5 , Figure 6 , Figure 7 The descriptions of the various embodiments shown will not be repeated here.

[0225] In some embodiments, the service governance policy includes a mapping between the network addresses of the second microservice and the second container group running the second microservice. The data card 120 is used to confirm the network address of the second container group running the second microservice according to the service governance policy, set the destination address of the first access request to the network address of the second container group, confirm that the second container group is located on the host 110, and send the modified first access request to the second container group through the data channel 140. For details, please refer to the description of Embodiment 1 above; further elaboration will not be repeated here.

[0226] In some embodiments, the service governance strategy further includes the mapping relationship between the network address of the third microservice and the network address of the third container group running the third microservice; the host 110 is also configured to obtain the second access request of the first microservice for the third microservice from the first container group, and send the second access request to the data card 120 through the data channel 140; the data card 120 is configured to confirm the network address of the third container group running the third microservice according to the service governance strategy, set the destination address of the second access request to the network address of the third container group, and confirm that the third container group is not located on the host 110, and send the second access request through the network. For details, please refer to the above description of Embodiment 2, which will not be repeated here.

[0227] In one example of these embodiments, node 100 further includes a network interface card (NIC) 130, which is connected to a data card 120. The data card 120 accesses the network through the NIC 130. The data card 120 is used to send a second access request to the NIC 130; the NIC 130 is used to send the second access request over the network. For details, please refer to the description of Embodiment 2 above, which will not be repeated here.

[0228] See one example of this example. Figure 4The service mesh system also includes nodes 200, each comprising a host 210, a data card 220, and a network card 230. The data card 220 is inserted into the host 210, and a data channel 240 is established between the data card 220 and the host 210. A third container group runs on the host 210. The network card 230 is connected to the data card 220 and is connected to the network. The data card 220 is also used to set a service mesh identifier for the second access request if it is confirmed that the third container group is not located on the host 210. The network card 230 is used to receive the second access request sent by the network card 230, and if it is confirmed that the second access request carries a service mesh identifier, it sends the second access request to the data card 220. The data card 220 is used to send the second access request to the third container group through the data channel 240 if it is confirmed that the third container group is located on the host 210. For details, please refer to the above description of Embodiment 2; further details will not be repeated here.

[0229] In some embodiments, the service mesh system further includes nodes 200, each including a host 210. Hosts 210 and 110 are connected to the network. A first application runs on host 110, and a second application runs on host 210. Host 110 is configured to obtain a third access request from the first application for the network address of the second application, and if it is confirmed that the second application is not running on host 110, it sends the third access request over the network. Host 210 is configured to receive the third access request sent by host 110 and forward the third access request to the second application. For details, please refer to the description of Embodiment 3 above; further details will not be repeated here.

[0230] In some embodiments, host 110 runs a first application and a second application. Host 110 is configured to obtain a third access request from the first application for the network address of the second application, and if it confirms that host 110 is running the second application, send the third access request to the second application. For details, please refer to the description of Embodiment 5 above; it will not be repeated here.

[0231] In some embodiments, the service mesh system further includes a node 200, which includes a host 210 and a data card 220. The data card 220 is inserted into the host 210, and a data channel 240 is provided between the data card 220 and the host 210. A fourth container group runs on the host 210, and a fourth microservice is configured in the fourth container group. The data card 220 and the host 110 are connected to the network. The host 110 runs a first application, which is used to obtain a fourth access request from the first application for the network address of the data card 220, and send the fourth access request through the network. The data card 220 is used to receive the fourth access request sent by the host 110, and send the fourth access request to the fourth microservice through the data channel 240 according to the identifier of the fourth microservice carried in the fourth access request. For details, please refer to the description of Embodiment 7 above, which will not be repeated here.

[0232] In some embodiments, the service mesh system further includes a node 200, which includes a host 210. A third application runs on the host 210, which is connected to a network. The host 210 is configured to obtain a fifth access request from the first microservice for the network address of the third application and send the fifth access request to the data card 120 via data channel 140. The data card 120 is configured to send the fifth access request over the network. The host 210 is configured to receive the fifth access request and send it to the third application. For details, please refer to the description of Embodiment Eight above; further details will not be repeated here.

[0233] See Figure 15 This application provides a data processing method. This method can be applied to... Figure 4 The service mesh system shown. (For example...) Figure 15 As shown, the method includes the following steps.

[0234] Step 1501: Data card 120 receives the service governance policy sent by the control node via the network.

[0235] Step 1502: Data card 120 performs service governance on the first access request sent by host 110 to data card 120 via data channel 140 according to the service governance policy. The first access request is an access request from the first microservice obtained by host 110 from the first container group for the second microservice.

[0236] For details, please refer to the above text. Figure 5 , Figure 6 , Figure 7 The descriptions of the various embodiments shown will not be repeated here.

[0237] In some embodiments, the service governance policy includes the mapping relationship between the network addresses of the second microservice and the second container group running the second microservice; step 1502 includes: the data card 120 confirms the network address of the second container group running the second microservice according to the service governance policy, and sets the destination address of the first access request to the network address of the second container group; the data card 120 confirms that the second container group is located on the host 110, and sends the modified first access request to the second container group through the data channel 140. For details, please refer to the above description of Embodiment 1, which will not be repeated here.

[0238] In some embodiments, the service governance strategy further includes the mapping relationship between the network addresses of the third microservice and the third container group running the third microservice; the method further includes: the host 110 obtaining a second access request from the first container group for the third microservice from the first microservice, and sending the second access request to the data card 120 through the data channel 140; the data card 120 confirming the network address of the third container group running the third microservice according to the service governance strategy, and setting the destination address of the second access request to the network address of the third container group; the data card 120 confirming that the third container group is not located on the host 110, and sending the second access request through the network. For details, please refer to the above description of Embodiment 2, which will not be repeated here.

[0239] In one example of these embodiments, node 100 further includes a network interface card (NIC) 130, which is connected to a data interface card (NIC) 120. The data interface card 120 accesses the network through the NIC 130. The data interface card 120 confirms that the third container group is not located on host 110 and sends a second access request over the network, including: the data interface card 120 confirms that the third container group is not located on host 110 and sends a second access request to the NIC 130; the NIC 130 sends the second access request over the network. For details, please refer to the above description of Embodiment 2, which will not be repeated here.

[0240] In one example of this example, the service mesh system also includes node 200, which includes host 210, data card 220, and network card 230. Data card 220 is inserted into host 210, and a data channel 240 is established between data card 220 and host 210. A third container group runs on host 210. Network card 230 is connected to data card 220 and is connected to the network. The method further includes: if data card 120 confirms that the third container group is not located on host 110, it sets a service mesh identifier for the second access request; network card 230 receives the second access request sent by network card 130, and if it confirms that the second access request carries a service mesh identifier, it sends the second access request to data card 220; if data card 220 confirms that the third container group is located on host 210, it sends the second access request to the third container group through data channel 240. For details, please refer to the above description of embodiment two, which will not be repeated here.

[0241] In some embodiments, the service mesh system further includes node 200, node 200 including host 210, host 210 and host 110 are connected to the network, host 110 runs a first application, and host 210 runs a second application; the method further includes:

[0242] Host 110 obtains a third access request from the first application for the network address of the second application. If host 110 confirms that the second application is not running, it sends the third access request over the network. Host 210 receives the third access request from host 110 and forwards it to the second application. For details, please refer to the above description of Embodiment 3; further elaboration will not be repeated here.

[0243] In some embodiments, a first application and a second application are running on the host 110; the method further includes: the host 110 obtaining a third access request from the first application for the network address of the second application, and if it is confirmed that the host 110 is running the second application, sending the third access request to the second application. For details, please refer to the description of Embodiment 5 above, which will not be repeated here.

[0244] In some embodiments, the service mesh system further includes a node 200, which includes a host 210 and a data card 220. The data card 220 is inserted into the host 210, and a data channel 240 is established between the data card 220 and the host 210. A fourth container group runs on the host 210, and a fourth microservice is configured in the fourth container group. The data card 220 and the host 110 are connected to the network, and a first application runs on the host 110. The method further includes: the host 110 obtaining a fourth access request from the first application for the network address of the data card 220, and sending the fourth access request through the network; the data card 220 receiving the fourth access request sent by the host 110, and sending the fourth access request to the fourth microservice through the data channel 240 according to the identifier of the fourth microservice carried in the fourth access request. For details, please refer to the description of Embodiment 7 above, which will not be repeated here.

[0245] In some embodiments, the service mesh system further includes a node 200, which includes a host 210 running a third application and connected to a network. The method further includes: the host 110 obtaining a fifth access request from the first microservice for the network address of the third application and sending the fifth access request to a data card 120 via a data channel 140; the data card 120 sending the fifth access request via the network; and the host 210 receiving the fifth access request and sending it to the third application. For details, please refer to the above description of Embodiment Eight, which will not be repeated here.

[0246] See Figure 16 This application also provides a network node 1600, including a host 1610 and a data card 1620. The data card 1620 is inserted into the host 1610. For example, as shown... Figure 16 As shown, the data card 1620 is inserted into the host 1610 via the PCIe interface.

[0247] The host 1610 may include a processor 1611 and a memory 1612. The memory 1612 stores computer instructions that can be executed by the processor 1611. The data card 1620 may include a processor 1621 and a memory 1622. The memory 1622 stores computer instructions that can be executed by the processor 1621. Specifically, when the computer instructions stored in memory 1612 are executed by the processor 1611, and the computer instructions stored in memory 1622 are executed by the processor 1621, the network node 1600 can perform [operations / functions]. Figure 5-15 The operations performed by node 100 or node 200 in the various embodiments shown.

[0248] It is understood that the processor in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor. It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application.

Claims

1. A microservice-based service mesh system, characterized in that, The first node comprises a first host and a first data card, the first data card is inserted into the first host, the first data card is provided with a first data channel with the first host, a first container group is running on the first host, and a first micro service is arranged in the first container group; The first data card accesses a network, receives a service management policy sent by a control node through the network, and performs service management on a first access request sent by the first host to the first data card through the first data channel according to the service management policy, wherein the first access request is an access request of the first micro service of the first container group to a second micro service; The service management policy comprises a correspondence between the second micro service and a network address of a second container group running the second micro service, wherein The first data card is configured to confirm the network address of the second container group running the second micro service according to the service management policy, set the destination address of the first access request as the network address of the second container group, confirm that the second container group is arranged on the first host, and send the modified first access request to the second container group through the first data channel.

2. The service mesh system of claim 1, wherein, The service management policy further comprises a correspondence between a third micro service and a network address of a third container group running the third micro service; The first host is further configured to obtain a second access request of the first micro service to the third micro service from the first container group, and send the second access request to the first data card through the first data channel; The first data card is configured to confirm the network address of the third container group running the third micro service according to the service management policy, set the destination address of the second access request as the network address of the third container group, and confirm that the third container group is not arranged on the first host, and send the second access request through the network.

3. The service mesh system of claim 2, wherein, The first node further comprises a first network card connected with the first data card, and the first data card accesses the network through the first network card, wherein The first data card is configured to send the second access request to the first network card; The first network card is configured to send the second access request through the network.

4. The service mesh system of claim 3, wherein, The second node comprises a second host, a second data card and a second network card, the second data card is inserted into the second host, the second data card is provided with a second data channel with the second host, the third container group is running on the second host, the second network card is connected with the second data card, and the second network card accesses the network, wherein The first data card is further configured to set a service mesh identifier for the second access request in the case that the third container group is not arranged on the first host. The second network card is configured to receive the second access request sent by the first network card, and send the second access request to the second data card if it is confirmed that the second access request carries the service mesh identifier. The second data card is configured to send the second access request to the third container group through the second data channel if it is confirmed that the third container group is arranged on the second host.

5. The service mesh system of any of claims 1-4, wherein, The third node further includes a third host, and the third host and the first host access the network, the first host runs the first application, and the third host runs the second application. The first host is configured to acquire a third access request of the first application for a network address of the second application, and send the third access request to the second application if it is confirmed that the first host does not run the second application. The third host is configured to receive the third access request sent by the first host, and send the third access request to the second application.

6. The service mesh system of any of claims 1-4, wherein, The first host runs the first application and the second application, and The first host is configured to acquire a third access request of the first application for a network address of the second application, and send the third access request to the second application if it is confirmed that the first host runs the second application.

7. The service mesh system of any of claims 1-4, wherein, The third node further includes a third host and a third data card, the third data card is arranged in the third host, the third data card and the third host are provided with a third data channel, the third host runs a fourth container group, the fourth container group is provided with a fourth micro service, and the third data card and the first host access the network. The first host runs the first application, and The first host is configured to acquire a fourth access request of the first application for a network address of the third data card, and send the fourth access request through the network. The third data card is configured to receive the fourth access request sent by the first host, and send the fourth access request to the fourth micro service through the third data channel according to an identifier of the fourth micro service carried in the fourth access request.

8. The service mesh system of any of claims 1-4, wherein, The third node further includes a third host, and the third host runs a third application, and the third host accesses the network. The first host is configured to acquire a fifth access request of the first micro service for a network address of the third application, and send the fifth access request to the first data card through the first data channel. The first data card is configured to send the fifth access request through the network. The third host is configured to receive the fifth access request, and send the fifth access request to the third application. 9.A method for service governance based on microservices, characterized in that, The application is applied to a micro-service-based service grid system, the service grid system comprises a first node, the first node comprises a first host and a first data card, the first data card is inserted into the first host, the first data card is provided with a first data channel with the first host, a first container group is running on the first host, a first micro-service is arranged in the first container group, and the first data card accesses a network; The method comprises: The first data card receives a service management strategy sent by a management node through the network; The first data card performs service management on a first access request sent by the first host to the first data card through the first data channel according to the service management strategy, wherein the first access request is an access request of the first micro-service in the first container group to a second micro-service; The service management strategy comprises a corresponding relationship between the second micro-service and a network address of a second container group running the second micro-service; The first data card performs service management on a first access request sent by the first host to the first data card through the first data channel according to the service management strategy, comprising: The first data card confirms the network address of the second container group running the second micro-service according to the service management strategy, sets the destination address of the first access request as the network address of the second container group; The first data card confirms that the second container group is arranged in the first host, and sends the modified first access request to the second container group through the first data channel.

10. The method of claim 9, wherein, The service management strategy further comprises a corresponding relationship between a third micro-service and a network address of a third container group running the third micro-service; The method further comprises: The first host obtains a second access request of the first micro-service to a third micro-service from the first container group, and sends the second access request to the first data card through the first data channel; The first data card confirms the network address of the third container group running the third micro-service according to the service management strategy, and sets the destination address of the second access request as the network address of the third container group; The first data card confirms that the third container group is not arranged in the first host, and sends the second access request through the network.

11. The method of claim 10, wherein, The first node further comprises a first network card connected with the first data card, and the first data card accesses the network through the first network card; The first data card confirms that the third container group is not arranged in the first host, and sends the second access request through the network, comprising: The first data card confirms that the third container group is not arranged in the first host, and sends the second access request to the first network card; The first network card sends the second access request through the network.

12. The method of claim 11, wherein, The service mesh system further comprises a second node comprising a second host, a second data card and a second network card, the second data card is inserted into the second host, the second data card is provided with a second data channel with the second host, the third container group is running on the second host, the second network card is connected with the second data card, and the second network card accesses the network; The method further comprises: The first data card sets a service mesh identifier for the second access request in a case that the third container group is not arranged on the first host; The second network card receives the second access request sent by the first network card, and sends the second access request to the second data card in a case that the second access request carries the service mesh identifier; The second data card sends the second access request to the third container group through the second data channel in a case that the third container group is arranged on the second host.

13. The method according to any one of claims 9-12, characterized in that, The service mesh system further comprises a third node comprising a third host, the third host and the first host access the network, the first host runs a first application, and the third host runs a second application; The method further comprises: The first host acquires a third access request of a network address of the second application for the first application, and sends the third access request to the second application in a case that the first host runs the second application. The first host runs a first application and a second application; 14. The method according to any one of claims 9-12, characterized in that, The method further comprises: The first host acquires a third access request of a network address of the second application for the first application, and sends the third access request to the second application in a case that the first host runs the second application. The service mesh system further comprises a third node comprising a third host, a third data card, the third data card is inserted into the third host, the third data card is provided with a third data channel with the third host, the third host runs a fourth container group, the fourth container group is provided with a fourth micro service, the third data card and the first host access the network, and the first host runs a first application; 15. The method according to any one of claims 9-12, characterized in that, The method further comprises: The first host acquires a fourth access request of a network address of the third data card for the first application, and sends the fourth access request through the network; The third data card receives the fourth access request sent by the first host, and sends the fourth access request to the fourth micro service through the third data channel according to the identifier of the fourth micro service carried in the fourth access request. The service mesh system further comprises a third node comprising a third host, the third host runs a third application, and the third host accesses the network; 16. The method according to any one of claims 9-12, characterized in that, The method further comprises: ​ The first host obtains a fifth access request of a network address of the first microservice for a third application, and sends the fifth access request to the first data card through the first data channel; The first data card sends the fifth access request through a network; The third host receives the fifth access request, and sends the fifth access request to the third application.

Images