Microservice-based service mesh system and service-oriented architecture management method

Abstract

The present application relates to the field of data processing technology, and more particularly to a microservice-based service mesh system and a service-oriented architecture management method. The system includes 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. A first data channel is established between the first data card and the first host. A first pod runs on the first host. A first microservice is provided in the first pod. The first data card accesses a network and receives a service-oriented architecture management policy sent by a management and control node through the network. Based on the service-oriented architecture management policy, the first data card performs service-oriented architecture management on a first access request sent by the first host to the first data card through the first data channel. The first access request is an access request of the first microservice for a second microservice and is obtained by the first host from the first pod. The system performs service-oriented architecture management for access requests from the host by using a data card inserted into the host, thereby saving host resources and improving service-oriented architecture management efficiency.

Description

[Technical field]

[0001] The present application relates to the data processing field, and in particular to a microservices-based service mesh system and a service-oriented architecture and a service-oriented architecture management method. [Background technology]

[0002] Service mesh technology is an application network technology based on traditional Internet Protocol (IP) networks. Based on service mesh technology, discovery and routing between services is based on service metadata information (including but not limited to service name and service version) instead of directly based on IP addresses. Service mesh technology separates the non-functional service-oriented architecture management logic of distributed applications in microservice architecture from service processes to sidecars, and non-intrusively provides connectivity, security, flow control, gray release, and observability between services to implement lightweight services and infrastructure-based service-oriented architecture management.

[0003] With the evolution of user requirements, the scale of microservices and the complexity of microservice invocations are growing rapidly. How to efficiently manage microservices in successive execution stages is a key issue in the evolution of service mesh technology. Summary of the Invention [Means for solving the problem]

[0004] The embodiments of the present application provide a microservice-based service mesh system and a service-oriented architecture management method to perform service-oriented architecture management for access requests by using a data card independent of the host, thereby saving host resources and improving service-oriented architecture management efficiency.

[0005] According to a first aspect, an embodiment of the present application provides 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. A first data channel is established between the first data card and the first host. A first pod runs on the first host. The first pod is provided with a first microservice. The first data card accesses a network and receives a service-oriented architecture management policy sent by the management and control node by using the network, and performs service-oriented architecture management on a first access request sent by the first host to the first data card through the first data channel based on the service-oriented architecture management policy. The first access request is an access request of the first microservice for a second microservice and is obtained by the first host from the first pod.

[0006] In other words, a node in a service mesh system can perform service-oriented architecture management on an access request by using peripheral devices of the host, thereby preventing the service-oriented architecture management on the access request from occupying host resources and improving service-oriented architecture management efficiency.

[0007] In one possible implementation, the service-oriented architecture management policy includes a correspondence between the second microservice and a network address of a second pod that executes the second microservice. The first data card is configured to determine, based on the service-oriented architecture management policy, the network address of the second pod that executes the second microservice, set a destination address of the first access request to the network address of the second pod, determine that the second pod is located on the first host, and send the modified first access request to the second pod via the first data channel.

[0008] In other words, in this embodiment, the data card can perform service-oriented architecture management for calls between different microservices on the same node.

[0009] In one possible embodiment, the service-oriented architecture management policy further includes a correspondence between the third microservice and a network address of a third pod that executes the third microservice. The first host is further configured to obtain a second access request of the first microservice for the third microservice from the first pod, and send the second access request to the first data card through the first data channel. The first data card is configured to determine a network address of the third pod that executes the third microservice based on the service-oriented architecture management policy, set a destination address of the second access request to the network address of the third pod, determine that the third pod is not located on the first host, and send the second access request by using the network.

[0010] In other words, in this embodiment, the data card can perform service-oriented architecture management for calls between microservices on different nodes.

[0011] In one possible implementation, the first node further includes a first network interface card. The first network interface card is connected to the first data card. The first data card accesses the network by using the first network interface card. The first data card is configured to send a second access request to the first network interface card. The first network interface card is configured to send the second access request by using the network.

[0012] In other words, in this embodiment, the data card can exchange information with the network by using a specially arranged network interface card, thereby reducing the overhead of data card resources caused by information exchange between the data card and the outside.

[0013] In one possible embodiment, the service mesh system further includes a second node. The second node includes a second host, a second data card, and a second network interface card. The second data card is inserted into the second host. A second data channel is established between the second data card and the second host. A third pod runs on the second host. The second network interface card is connected to the second data card. The second network interface card accesses the network. The first data card is further configured to set a service mesh identifier for the second access request if the third pod is not located on the first host. The second network interface card is configured to receive the second access request sent by the first network interface card, and send the second access request to the second data card if the second access request carries a service mesh identifier. The second data card is configured to transmit a second access request to the third pod over the second data channel if the second data card determines that the third pod is located on the second host.

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

[0015] In one possible embodiment, the service mesh system further includes a third node. The third node includes a third host. The third host and the first host access the network. The first application runs on the first host. The second application runs on the third host. The first host is configured to obtain a third access request of the first application for a network address of the second application, and transmit the third access request by using the network if the first host determines that the second application is not running on the first host. The third host is configured to receive the third access request transmitted by the first host and transmit the third access request to the second application.

[0016] In other words, in this embodiment, the service mesh system can implement invocations between common applications on different nodes.

[0017] In one possible implementation, the first application and the second application run on a first host, the first host being configured to obtain a third access request of the first application for a network address of the second application, and to send the third access request to the second application if the first host determines that the second application runs on the first host.

[0018] In other words, in this embodiment, the service mesh system can implement invocations between different common applications on the same node.

[0019] In one possible embodiment, the service mesh system further includes a third node. The third node includes a third host and a third data card. The third data card is inserted into the third host. A third data channel is established between the third data card and the third host. A fourth pod runs on the third host. A fourth microservice is provided in the fourth pod. The third data card and the first host access a network. The first application runs on the first host. The first host is configured to obtain a fourth access request of the first application for a network address of the third data card and transmit the fourth access request by using the network. The third data card is configured to receive the fourth access request transmitted by the first host and transmit the fourth access request to the fourth microservice via the third data channel based on an identifier carried in the fourth access request, the identifier being of the fourth microservice.

[0020] In other words, in this embodiment, the service mesh system can implement common application invocation of microservices by using data cards.

[0021] In one possible embodiment, the service mesh system further includes a third node. The third node includes a third host. The third application runs on the third host. The third host accesses the network. The first host is configured to obtain a fifth access request of the first microservice for a network address of the third application and send the fifth access request to the first data card via the first data channel. The first data card is configured to send the fifth access request by using the network. The third host is configured to receive the fifth access request and send the fifth access request to the third application.

[0022] In other words, in this embodiment, the service mesh system can implement the invocation of microservices of common applications by using data cards.

[0023] According to a second aspect, an embodiment of the present application provides a microservice-based service-oriented architecture management method. The method is applied to a microservice-based service mesh system. The service mesh system includes 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. A first data channel is established between the first data card and the first host. A first pod runs on the first host. The first pod is provided with a first microservice. The first data card accesses a network. The method includes the first data card receiving a service-oriented architecture management policy sent by the management and control node by using the network. The first data card performs service-oriented architecture management on a first access request sent by the first host to the first data card through the first data channel based on the service-oriented architecture management policy. The first access request is an access request of the first microservice to a second microservice and is obtained by the first host from the first pod.

[0024] In one possible implementation, the service-oriented architecture management policy includes a correspondence between the second microservice and a network address of a second pod that executes the second microservice. The first data card performing service-oriented architecture management on the first access request sent by the first host to the first data card over the first data channel based on the service-oriented architecture management policy includes the first data card determining, based on the service-oriented architecture management policy, a network address of the second pod that executes the second microservice and setting a destination address of the first access request to the network address of the second pod. The first data card determines that the second pod is located on the first host and sends the modified first access request to the second pod over the first data channel.

[0025] In one possible implementation, the service-oriented architecture management policy further includes a correspondence between the third microservice and a network address of a third pod that executes the third microservice. The method further includes the first host obtaining a second access request of the first microservice for the third microservice from the first pod and sending the second access request to the first data card through the first data channel. The first data card determines a network address of the third pod that executes the third microservice based on the service-oriented architecture management policy, and sets a destination address of the second access request to the network address of the third pod. The first data card determines that the third pod is not located on the first host, and sends the second access request by using the network.

[0026] In one possible implementation, the first node further includes a first network interface card. The first network interface card is connected to the first data card. The first data card accesses the network by using the first network interface card. The first data card determining that the third pod is not located on the first host and sending a second access request by using the network includes the first data card determining that the third pod is not located on the first host and sending a second access request to the first network interface card. The first network interface card sends the second access request by using the network.

[0027] In one possible embodiment, the service mesh system further includes a second node. The second node includes a second host, a second data card, and a second network interface card. The second data card is inserted into the second host. A second data channel is established between the second data card and the second host. A third pod runs on the second host. The second network interface card is connected to the second data card. The second network interface card accesses the network. The method further includes the first data card setting a service mesh identifier of the second access request if the method determines that the third pod is not located on the first host. The second network interface card receives the second access request sent by the first network interface card, and sends the second access request to the second data card if the method determines that the second access request carries a service mesh identifier. If the second data card determines that the third pod is located on the second host, it sends a second access request to the third pod over the second data channel.

[0028] In one possible embodiment, the service mesh system further includes a third node. The third node includes a third host. The third host and the first host access the network. The first application runs on the first host. The second application runs on the third host. The method further includes the first host obtaining a third access request of the first application for a network address of the second application and transmitting the third access request by using the network when the first host determines that the second application is not running on the first host. The third host receives the third access request transmitted by the first host and transmits the third access request to the second application.

[0029] In one possible implementation, the first application and the second application run on a first host. The method further includes, when the first host obtains a third access request of the first application for a network address of the second application and determines that the second application runs on the first host, sending the third access request to the second application.

[0030] In one possible implementation, the service mesh system further includes a third node. The third node includes a third host and a third data card. The third data card is inserted into the third host. A third data channel is established between the third data card and the third host. A fourth pod runs on the third host. A fourth microservice is provided in the fourth pod. The third data card and the first host access the network. The first application runs on the first host. The method further includes the first host obtaining a fourth access request of the first application for a network address of the third data card and sending the fourth access request by using 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 microservice via the third data channel based on an identifier carried in the fourth access request that is of the fourth microservice.

[0031] In one possible embodiment, the service mesh system further includes a third node. The third node includes a third host. The third application runs on the third host. The third host accesses the network. The method further includes the first host obtaining a fifth access request of the first microservice for a network address of the third application and sending the fifth access request to the first data card via the first data channel. The first data card sends the fifth access request by using the network. The third host receives the fifth access request and sends the fifth access request to the third application.

[0032] It should be understood that the service-oriented architecture management method provided in the second aspect is a method executed by a node in the service mesh system provided in the first aspect, and therefore, for beneficial effects that may be achieved by the service-oriented architecture management method, please refer to the corresponding beneficial effects described above.

[0033] According to a third aspect, an embodiment of the present application provides a network node including a host and a data card. The data card is inserted into the host. The host includes a first processor and a first memory. The first memory is configured to store a first computer instruction. The data card includes a second processor and a second memory. The second memory is configured to store a second computer instruction. When the network node is operated, the first processor executes the first computer instruction and the second processor executes the second computer instruction, such that the network node performs the method provided in the second aspect.

[0034] According to a fourth aspect, an embodiment of the present application provides a computer storage medium comprising computer instructions that, when executed on a network node, enable the network node to perform the method provided in the second aspect.

[0035] According to a fifth aspect, an embodiment of the present application provides a computer program product, the computer program product comprising program code which, when executed by a processor used in a network node, performs the method provided in the first aspect.

[0036] According to the service mesh system and service-oriented architecture management method provided in the embodiments of the present application, a data card that can be independently computed can be used to perform service-oriented architecture management on an access request used to invoke a service, so that the service-oriented architecture management no longer occupies the computing resources of the host, thereby saving the computing resources of the host and improving the efficiency of service-oriented architecture management. [Brief description of the drawings]

[0037] [Figure 1]A service-oriented architecture management framework is presented. [Diagram 2] 1 illustrates a service mesh system. [Diagram 3] 1 illustrates a service mesh system. [Figure 4] 1 illustrates a service mesh system according to an embodiment of the present application. [Figure 5A] 5 is a flowchart of an application invocation based on the service mesh system shown in FIG. 4. [Figure 5B] 5 is a flowchart of an application invocation based on the service mesh system shown in FIG. 4. [Figure 6] 4 is a flow chart of node initialization according to an embodiment of the present application. [Figure 7] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 8A] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 8B] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 9] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 10A] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 10B] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 11] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 12A] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 12B] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 13A] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 13B] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 14A] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 14B] 4 is a flowchart of an application invocation according to an embodiment of the present application. [Figure 15] 1 is a flowchart of a service-oriented architecture management method according to an embodiment of the present application. [Figure 16] FIG. 2 is a schematic block diagram of a network node according to an embodiment of the present application; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0038] Hereinafter, technical solutions in embodiments of the present invention will be described with reference to the accompanying drawings. It is apparent that the described embodiments are only a part, rather than all, of the embodiments in this specification.

[0039] In the description herein, references to "one embodiment," "some embodiments," and the like indicate that one or more embodiments herein include a particular feature, structure, or characteristic that is described with reference to the embodiment. Thus, statements such as "in one embodiment," "in some embodiments," "in some other embodiments," and "in some other embodiments" appearing in different places in the specification do not necessarily refer to the same embodiment, unless specifically emphasized otherwise, but may mean "one or more, but not all, embodiments."

[0040] In the description of the present specification, unless otherwise specified, " / " means "or". For example, A / B may represent A or B. In the present specification, "and / or" describes only the related relationship between related objects and represents that three relationships may exist. For example, A and / or B may represent three cases: only A exists, both A and B exist, and only B exists. In addition, in the description of the embodiments of the present specification, "multiple" means two or more than two.

[0041] In the present description, the terms "first" and "second" are merely intended to be descriptive and should not be understood as an indication or implication of relative importance or an implicit indication of the quantity of the technical features indicated. Thus, a feature qualified by "first" or "second" may explicitly or implicitly include one or more features. The terms "comprise", "contain", "have" and variations thereof all mean "including, but not limited to", unless specifically emphasized otherwise.

[0042] Microservices architecture is a service oriented architecture (SOA) that breaks down a complex system into multiple smaller services or applications. The smaller services or applications may be called microservices. Each microservice is responsible for implementing an independent service logic. Microservices are built on service functions and may be deployed independently. Microservices depend on each other to provide a set of functionality. Microservices are easily understood and modified, offering flexibility in language and framework choice.

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

[0044] Figure 1 shows a service-oriented architecture management framework based on a software development kit (SDK). Typical applications of the framework include springcloud and dubbo. In this framework, a client or a server provides a service-oriented architecture management function. The service-oriented architecture management function is usually implemented by an SDK. In the development stage of the framework, a client or a server needs to be developed using the SDK provided by the framework. Generally, the development of the framework only supports a specific programming language, e.g., Java. The framework is characterized by high performance and easy debugging. However, an existing client or server in another programming language cannot be included in the framework, and it is difficult to reconstruct the framework, so an intrusive reconstruction is necessary. As a result, unnecessary risks and development costs are caused.

[0045] Figure 2 illustrates a system that can perform functions such as auto-deployment, auto-scaling, and maintenance of a container cluster. Containers can be used to deploy or configure microservices.

[0046] The system shown in Figure 2 uses a pod-level sidecar as a proxy for an application or microservice, and can provide service-oriented architecture management features that are transparent to the user, such as link encryption, circuit breakers, traffic throttling, gray release, or link tracing. Unlike traditional network proxies, Istio does not simply perform load balancing operations on target IP addresses at the kernel or hardware layer, but the sidecar is responsible for discovering and load balancing target services. The caller only needs to access the virtual or logical address of the service. The sidecar determines how to translate the service metadata into an actual accessible network address and sends traffic to the called microservice based on the network address.

[0047] FIG. 3 shows a system in which a pod-level sidecar can be deployed, or a node-level sidecar can be deployed.

[0048] Regardless of the system shown in Figure 2 or the system shown in Figure 3, the sidecar brings transparent service-oriented architecture management capabilities and also occupies excess host resources (e.g., CPU and memory). Especially in public cloud environments, a large number of pods need to be deployed, which brings extra overhead on host resources. When a service is busy, the sidecar and microservices may preempt each other's resources. When the CPU is overloaded, input / output (I / O) cannot be processed in a timely manner. As a result, congestion may occur in the sidecar, which increases the latency of the entire link.

[0049] An embodiment of the present application provides a microservice-based service mesh system, see Fig. 4. The service mesh system may include a node 100. The node 100 may include a host 110, a data card 120, and a network interface card 130.

[0050] The host 110 may be a physical machine, such as a server. One or more pods may run on the host 110. Each pod may include one or more containers. For example, the pod may be a K8s pod. One or more microservices may be deployed on the host 110. Each microservice may be configured or executed within a pod. A microservice may be also called a microservice application and may implement an independent service logic. Multiple microservices may provide corresponding service functions based on calls and calling relationships.

[0051] The data card 120 is a hardware device having independent computing resources. For example, the data card 120 has a dedicated processor, a dedicated memory, and the like. For example, the data card 120 may be a software defined infrastructure (SDI). The data card 120 may be referred to as an SDI data card. The data card 120 may be used as a peripheral device of the host 110 and is inserted into the host 110. The data card 120 may perform service-oriented architecture management for an access request from the host 110. For example, a sidecar corresponding to a microservice on the host 110 may be deployed on the data card 120, so that the data card 120 can function as a sidecar. Since the computing resources of the data card 120 are independent from the computing resources of the host 110, the data card 120 plays the role of a sidecar, thereby preventing the sidecar from preempting the computing resources of the host 110 when performing service-oriented architecture management. In addition, the computing resources of the nearby data card 120 may be used during the execution of the sidecar, so that the service-oriented architecture management efficiency may be improved and the network delay may be reduced.

[0052] As shown in FIG. 4, a data channel 140 is established between the host 110 and the data card 120. The host 110 can send an access request that needs to perform service-oriented architecture management to the data card 120 through the data channel 140, so that the data card 120 performs service-oriented architecture management, such as encryption and load balancing, on the access request. For example, the data channel 140 can be a peripheral component interconnect express (PCIe) bus, or the data channel 140 is carried on a PCIe bus. In one example, the data channel 140 can receive an access request sent by the host 110 based on a remote direct memory access (RDMA) technology. Specifically, the host 110 can directly send an access request to a storage area of ​​the data card 120 through the data channel 140. Thus, high-speed data transmission between the host and the data card is implemented, and network latency is further reduced.

[0053] The network interface card 130 accesses the network 300, transmits data to the network 300, and retrieves data from the network 300. The network interface card 130 can be communicatively connected to the host 110 and the data card 120 separately, such that the network interface card 130 can transmit data retrieved from the host 110 or the data card 120 to the network 300, and transmit data retrieved from the network 300 to the host 110 or the data card 120. For example, the network interface card 130 may be a peripheral device inserted into the host 110. In one example, the network interface card 130 is specifically an SDI. The network interface card 130 may also be referred to as an SDI network interface card.

[0054] In some embodiments, the network interface card 130 and the data card 120 may be two separate hardware cards or hardware devices. In some embodiments, the network interface card 130 and the data card 120 may be located on one hardware card or hardware device.

[0055] In some embodiments, further refer to Figure 4. The service mesh system may further include a node 200. For the host 210, the data card 220, the network interface card 230, and the data channel 240 included in the node 200, please refer to the above implementation of the host 110, the data card 120, the network interface card 130, and the data channel 140. Details will not be repeated here.

[0056] The service mesh system may further include more nodes. For each node, please refer to the implementation of node 100. Details will not be repeated here.

[0057] An example of the structure of the service mesh system provided in the present embodiment of the present application has been described above. Next, an example of the functions of modules or components in the service mesh system in different embodiments will be described.

[0058] 5A and 5B are flowcharts of application invocation based on the service mesh system shown in FIG.

[0059] As shown in FIG. 5A and FIG. 5B, one or more pods may be arranged on the host 110. Specifically, the operating system (e.g., Linux) of the host 110 may be divided into a user space and a system kernel. The one or more pods may operate in the user space. The one or more pods may include a pod 111 and a pod 112. A microservice 1111 and a network port 1112 are arranged on the pod 111. The microservice 1111 can generate an access request to call a service provided by another microservice or application. The service provided by the microservice 1111 may be called by another microservice or application. The microservice 1111 can send data to the outside or receive data from the outside via the network port 1112. A microservice 1121 and a network port 1122 are arranged on the pod 112. The microservice 1121 can generate an access request to call a service provided by another microservice or application. The services provided by microservice 1121 may be invoked by other microservices or applications. Microservice 1121 can send data to the outside world and receive data from the outside world via network port 1122.

[0060] A common application 113 may further be located on the host 110. The common application may be an application other than a microservice, for example, an application based on a secure shell protocol (SSH) or a remote terminal protocol (telnet). The common application 113 may call a service provided by a microservice or may call another common application. The service provided by the common application 113 may be called by a microservice or another common application. In this embodiment of the present application, the common application may also be referred to as a common service.

[0061] The traffic blocking module 114 may further be disposed in the host 110. The traffic blocking module 114 may select an access request that requires the service-oriented architecture management to be performed, and send the access request that requires the service-oriented architecture management to the data card 120 via the data channel 140. The traffic blocking module 114 may be disposed in a system kernel.

[0062] Specifically, an access request generated by a microservice on the host 110 may include a service identifier. The access request is used to request that a network connection be established between the access request and the target application of the access request so that the target application provides a service to the microservice generating the access request. The target application of the access request may be another microservice or may be a common application. In general, the service identifier may be a logical address or descriptive information, not a network address of a particular microservice or application, or not a network address of a pod running the microservice or application. The service identifier may be used to describe or identify a service. In other words, the service identifier is used to describe or represent the service requested by the access request in which the service identifier is located. In one example, the service identifier may include a service name, a service version number, etc. In one example, the service identifier may be preconfigured information used to declare or indicate that a service-oriented architecture management needs to be performed on the access request. The traffic interception module 114 may have a management mandatory list that includes a plurality of service identifiers. For example, the traffic interception module 114 may obtain the management mandatory list from a control plane proxy. The management mandatory list in the control plane proxy may be obtained from the control plane. In one example, the management must-know list may be generated by a control plane proxy, hi another example, a developer or an operation and maintenance personnel of the service mesh system may configure the management must-know list in the control plane.

[0063] In addition, it will be appreciated that the target application of the access request is not actually determined before the service-oriented architecture management is performed for the access request for which the service-oriented architecture management needs to be performed. The operation of the service-oriented architecture management is to determine the target application of the access request based on the service identifier in the access request.

[0064] The traffic interception module 114 obtains an access request from the user space of the host 110, and determines whether a service identifier in the access request is located in the management required list. If the service identifier in the access request is located in the management required list, it can be determined that the access request is an access request for which service-oriented architecture management needs to be performed, and the access request is sent to the data card 120. If the service identifier in the access request is not located in the management required list, it can be determined that there is no need to perform service-oriented architecture management on the access request, and the access request can be directly sent to the network 300 by using the network interface card 130, so that the access request is sent to the corresponding node by using the network 300. For example, the service identifier in the access request may be a network address of a common application, and the network address is not located in the management required list. The network interface card 130 can directly send the service request to the corresponding application based on the network address.

[0065] Further referring to Figures 5A and 5B, the data card 120 may include a communication proxy 121, a user mode protocol stack 122, and a control plane proxy 123. The communication proxy 121 may perform service-oriented architecture management on the access request, for example, encrypting / decrypting the access request, and determining a microservice or application that provides the service requested by the access request. For example, the communication proxy 121 may be a sidecar or may have a function of a sidecar. More specifically, in one example, the communication proxy 121 may be a sidecar in a K8s system or may have a function of a sidecar in a K8s system.

[0066] The user mode protocol stack 122 may be configured to forward the access request to the communication proxy 121 and to forward the access request sent by the communication proxy 121 to another module or component. The specific functions of the user mode protocol stack 122 are described in the specific embodiments below and will not be repeated in detail here.

[0067] The node 200 includes a host 210, a data card 220, a network interface card 230, and a data channel 240. A common application 211, a common application 212, a pod 213, and a pod 214 are disposed on the user space side of the host 210. A special microservice 2131 and a network port 2132 are disposed on the pod 213. A special microservice 2141 and a network port 2142 are disposed on the pod 214. A traffic interception module 215 is disposed on the system kernel side of the host 210. The data card 220 may include a communication proxy 221, a user mode protocol stack 222, a control plane proxy 223, etc. For the functions of the components or modules in the node 200, please refer to the above description of the corresponding components or modules in the node 100. Details will not be repeated here.

[0068] After the service mesh system is started, the nodes in the service mesh system can be initialized, see Figure 6. Node 100 is used as an example, and the initialization of node 100 can include the following steps:

[0069] The control plane proxy 123 may perform step 601 of sending an instruction to the user mode protocol stack 122 not to block the inbound and outbound traffic of the control plane proxy. The inbound and outbound traffic of the control plane proxy 123 is data sent by the control plane proxy 123 and data received by the control plane proxy 123. The instruction includes the user identity (UID) of the control plane proxy. The user mode protocol stack 122 may not block the traffic (or data) sent by the control plane proxy and may not block the traffic sent to the control plane based on the user identity of the control plane proxy. In other words, the user mode protocol stack 122 can identify the inbound and outbound traffic of the control plane proxy based on the user identification information of the control plane proxy, and therefore cannot block the inbound and outbound traffic of the control plane proxy 123, so that the inbound and outbound traffic of the control plane proxy 123 can pass freely through the user mode protocol stack 122.

[0070] The control plane proxy 123 may perform step 602 of receiving the service list, service-oriented architecture management policies, and special microservices list sent by the control plane 400.

[0071] The control plane 400 is a control plane in a service mesh. The control plane 400 may be called a management and control node. Alternatively, the control plane 400 may be a program or module that runs on the management and control node and has control and management functions.

[0072] The service list may include a list of correspondences between service identifiers and network addresses of microservices or applications that can provide the services corresponding to the service identifiers. A microservice may register with the control plane 400 a name of the microservice, a service identifier, a network address of a pod running the microservice, and the like. For example, the network address of the pod may include an IP address and a port number of the pod. Thus, the control plane 400 may obtain the service list based on the correspondences between the service identifiers that build the microservices and the network addresses of the pods running the microservices.

[0073] In some embodiments, the service list may be referred to as a service-oriented architecture management policy, or a service-oriented architecture management policy includes the service list.

[0074] In some embodiments, the service-oriented architecture management policy may include policies such as whether to encrypt or decrypt an access request and whether to perform load balancing on the access request. Furthermore, for specific implementations of the service-oriented architecture management policy, please refer to the description of the related art. Details will not be repeated here.

[0075] The special microservice list includes identification information of one or more special microservices. It will be understood that in general, in a service mesh system, service-oriented architecture management needs to be performed twice for an access request used to request to connect to a microservice. One service-oriented architecture management is performed by the communication proxy of the sender (e.g., node 100), and another service-oriented architecture management is performed by the communication proxy of the receiver (e.g., node 100). However, a special microservice is special. Specifically, service-oriented architecture management needs to be performed only once for an access request used to request to connect to a special microservice.

[0076] Please continue to refer to FIG. 6. The control plane proxy 123 may perform step 603a of sending the management mandatory list to the traffic blocking module 114. In some embodiments, the management mandatory list may be configured by a developer or an operation and maintenance personnel of the service mesh system. In some embodiments, the control plane proxy 123 may automatically generate the management mandatory list based on the service list. As described above, the service list may include a list of correspondences between service identifiers and network addresses of microservices or applications that can provide the services corresponding to the service identifiers. The control plane proxy 123 may use the service identifiers in the service list as the management mandatory list. It should be noted that two methods of configuring the management mandatory list are described above. However, during the specific implementation of the solution provided in this embodiment of the present application, a method of automatically generating the management mandatory list based on the service list is likely to be used to further reduce the dependency on human labor.

[0077] The control plane proxy 123 may perform step 603b of sending the special microservice list to the user mode protocol stack 122. Upon receiving the access request, the user mode protocol stack 122 may determine whether the microservice for which the access request is used to request the connection is located in the special microservice list. If the microservice for which the access request is used to request the connection is in the special microservice list, the user mode protocol stack 122 does not send the access request to the communication proxy 121 and sends the access request directly to the host 110.

[0078] The control plane proxy 123 may further perform step 603c of sending the service list and the service-oriented architecture management policy to the communication proxy 121, so that the communication proxy 121 may perform service-oriented architecture management on the access request based on the service list and the service-oriented architecture management policy. Specifically, a connection target application of the access request may be determined based on the service list by using a service identifier in the access request. Specifically, a network address of the target application of the access request is determined. For example, if the service-oriented architecture management policy includes an encryption policy, the communication proxy 121 may encrypt the access request.

[0079] The control plane proxy 123 may further perform step 604 of receiving an updated service list, an updated service-oriented architecture management policy, and an updated special microservices list from the control plane 400.

[0080] The control plane proxy 123 may further perform step 605a of sending the updated management mandatory list to the traffic blocking module 114. In some embodiments, the updated management mandatory list may be generated by the control plane proxy 123 based on the updated service list.

[0081] The control plane proxy 123 may further perform step 605b of sending the updated special microservices list to the user mode protocol stack 122.

[0082] The control plane proxy 123 may further perform a step 605 d of sending the updated service list and the updated service oriented architecture management policies to the communication proxy 121 .

[0083] The initialization of the node 100 can be implemented by using the steps described above. For the initialization of another node, please refer to the embodiment of the initialization of the node 100. The details will not be repeated here.

[0084] After the above initialization is performed on the nodes in the service mesh system, the following call can be made:

[0085] (1) A microservice on node 100 calls another microservice on node 100.

[0086] (2) A microservice on node 100 calls a service on node 200.

[0087] (3) The common application on node 100 calls the common application on node 200.

[0088] (4) The microservice on node 100 calls a special microservice on node 200. The special microservice will be described in detail below. Details will not be repeated here.

[0089] (5) A common application on node 200 invokes another common application on node 200.

[0090] (6) Node 200 forwards the access request from node 100.

[0091] (7) The common application on node 100 invokes a microservice on node 200.

[0092] (8) The microservice on node 100 invokes the common application on node 200.

[0093] Next, the above eight calling cases will be specifically described in different embodiments.

[0094] Example 1: A microservice on node 100 invokes another microservice on node 100.

[0095] In this embodiment, the microservice 1111 calls the microservice 1121 is used as an example. In order to establish a communication connection between the microservice 1111 and the microservice 1121 so that the microservice 1121 can provide a service related to the microservice 1111, the microservice 1111 can generate an access request used to connect to the microservice 1121. In this way, the microservice 1111 calls the microservice 1121. It can be understood that in the microservice architecture, when generating an access request, the microservice 1111 does not actually know that the microservice 1111 needs to connect to the microservice 1121, but only knows which service is required by the microservice 1111, and further adds a service identifier of the service to the access request or uses the service identifier as the original destination address of the access request. After performing the service-oriented architecture management on the access request, the communication proxy can determine a target application that actually provides a service to the microservice 1111, and then forward the access request to the target application to establish a connection between the microservice 1111 and the target application.

[0096] Next, a specific data transfer path in which the microservice 1111 calls the microservice 1121 will be described with reference to FIG. 7, FIG. 5A, and FIG. 5B.

[0097] The microservice 1111 may generate an access request A1. The access request A1 may include a service identifier of a service that may be provided by the microservice 1121. For example, the access request A1 may be a network socket (socket) connection request. The service identifier in the access request A1 may be referred to as the original socket destination address (destination, DST) of the access request A1. The microservice 1111 may perform a step 701 of sending the access request A1 to the traffic blocking module 114. The traffic blocking module 114 may determine whether a service-oriented architecture management needs to be performed on the access request A1 based on the service identifier in the access request A1 by using a management mandatory list. If the service identifier in the access request A1 is a service identifier corresponding to the microservice 1121 and the service identifier is in the management mandatory list, it is determined that a service-oriented architecture management needs to be performed on the access request A1. Thus, the traffic blocking module 114 may perform a step 702 of forwarding the access request A1 to the data channel 140.

[0098] In an illustrative example, the data flow of step 701 and step 702 may be shown in (1) of FIG. 5A. The access request A1 may be generated by the microservice 1111 and may be a network socket connection request. The service identifier in the access request A1 may be used as the original socket destination address of the socket connection. The access request A1 may be sent to the traffic interception module 114. Through analysis, the traffic interception module 114 learns that the service corresponding to the service identifier is a service in the service mesh. In other words, it is necessary to perform service-oriented architecture management on the service corresponding to the service identifier. The traffic interception module 114 forwards the access request A1 to the data channel 140.

[0099] The data channel 140 may execute step 703 of sending the access request A1 to the user mode protocol stack 122. For step 703, see (2) of FIG. 5A. For example, as described above, the data channel 140 is a PCIe bus or is carried on a PCIe bus. In step 703, the end of the data channel 140 located in the host 110 may convert the access request A1 into a data flow under the PCIe protocol and send the converted data flow through the data channel 140. The end of the data channel 140 located in the data card 120 may convert the access request A1 presented as a data flow under the PCIe protocol into the form of a socket connection request and send the access request A1 to the user mode protocol stack 122. In addition, in this embodiment of the present application, the user mode protocol stack 122 is independent of the network protocol stack embedded in the operating system of the host 110. Therefore, the system overhead caused by the data exchange between the host 110 and the data card 120 may be avoided or reduced.

[0100] The user mode protocol stack 122 may execute step 704 of sending the access request A1 to the communication proxy 121. For step 704, see (2) of FIG. 5A. For example, the user mode protocol stack 122 may store the service identifier in the access request A1, i.e., the original socket destination address of the access request A1. The user mode protocol stack 122 may update the socket destination address of the access request A1 to the network address of the listening port 1 of the communication proxy 121, and thus may send the access request A1 to the listening port 1. In this case, a socket connection or socket link may be established between the microservice 1111 and the listening port 1. The listening port 1 may also be referred to as the outbound traffic listening port of the communication proxy 121.

[0101] The communication proxy 121 can obtain the access request A1 through the listening port 1 and obtain the service identifier in the access request A1. It can be understood that the user mode protocol stack 122 is located on the socket link between the microservice 1111 and the listening port 1 and stores the service identifier in the access request A1. The communication proxy 121 can obtain the service identifier in the access request A1 from the user mode protocol stack 122 by using the socket link.

[0102] The communication proxy 121 may execute step 705 of performing service-oriented architecture management on the access request A1. Specifically, the communication proxy 121 may execute the service-oriented architecture management based on the service identifier in the access request A1 and the service-oriented architecture management policy. The service-oriented architecture management may include selecting an application that provides the service described by the service identifier of the microservice 1111 through load balancing. In this embodiment, it may be determined that the selected application that provides the service described by the service identifier of the microservice 1111 is the microservice 1121. In other words, it may be determined that the microservice 1121 is the target application of the access request A1. For example, when the target application of the access request A1 is determined, the socket destination address of the access request A1 may be updated to the network address of the microservice 1121. The network address of the microservice 1121 may specifically be the network address of the pod running the microservice 1121, i.e., the network address of the pod 112. For example, the network address of the pod 112 may include the IP address and port number of the pod 112.

[0103] The communication proxy 121 may execute step 706 of sending the access request A1 to the user mode protocol stack 122. The user mode protocol stack 122 may execute step 707 of determining that the target application of the access request A1 is located on this node. The user mode protocol stack 122 may then execute step 708 of sending the access request A1 to the listening port 2 of the communication proxy 121. For details, see (3) and (6) of FIG. 5A. The user mode protocol stack 122 may determine that step 706 is performed by the communication proxy 121 based on the user identity (UID) of the sending process of the access request A1, and may determine that the target application of the access request A1 (i.e., the microservice 1121) is located on this node (i.e., the node 100) based on the socket destination address in the access request A1. Then, in step 706, the user mode protocol stack 122 may determine that the user mode protocol stack 122 receives inbound traffic of the access request A1 and forwards the access request A1 to the listening port 2 of the communication proxy 121. This ensures that even if the microservice calls another local microservice, the microservice can symmetrically enter the communication proxy twice and perform the service-oriented architecture management twice. The listening port 2 may be referred to as the inbound traffic listening port of the communication proxy 121.

[0104] The communication proxy 121 can again execute step 709 of performing service-oriented architecture management on the received access request A1. For example, in the service-oriented architecture management in step 705, the service data or user data in the access request A1 is encrypted. In this case, in the service-oriented architecture management in step 709, the encrypted data can be decrypted.

[0105] The communication proxy 121 may perform step 710 of sending the access request A1, for which the service-oriented architecture management is executed again, to the user mode protocol stack 122. Before performing step 710, the communication proxy 121 may call an application programming interface (API) provided by the user mode protocol stack 122 to add a service-oriented architecture management identifier to the access request A1. The service-oriented architecture management identifier is used to indicate that the service-oriented architecture management is executed twice for the access request A1 and the target application is deployed locally.

[0106] The user mode protocol stack 122 may perform step 711 of transmitting the access request A1 to the data channel 140. See (7) and (8) of FIG. 5A. Upon receiving the access request A1 transmitted in step 710, the user mode protocol stack 122 may determine that the access request A1 is inbound traffic and the target application is located in the pod of this node based on the service-oriented architecture management identifier carried in the access request A1. Thus, the user mode protocol stack 122 may perform step 711 of transmitting the access request A1 to the data channel 140.

[0107] The data channel 140 may perform step 712 of sending the access request A1 to the traffic interception module 114. See (8) in FIG. 5A. Upon receiving the access request A1 sent in step 711, the end of the data channel 140 located in the data card 120 may convert the access request A1 into a data flow under the PCIe protocol and send the data flow under the PCIe protocol to the host 110. When the data flow under the PCIe reaches the end of the data channel 140 located in the host 110, the data flow under the PCIe may be converted into a socket connection request.

[0108] The traffic blocking module 114 is specifically an outbound traffic blocking module. In other words, the traffic blocking module 114 blocks or filters only traffic sent to the outside by the host 110, and does not filter traffic received from the outside by the host 110. Upon receiving the access request A1 sent in step 712, the traffic blocking module 114 can send the access request A1 to the target application (i.e., the microservice 1121) based on the socket destination address (i.e., the network address of the microservice 1121) of the access request A1. In this way, a socket connection between the microservice 1111 and the microservice 1121 is established, and the microservice 1111 can call the microservice 1121.

[0109] Example 2: A microservice on node 100 invokes a microservice on node 200.

[0110] In this embodiment, the microservice 1111 calls the microservice 2141 is used as an example. In order to establish a communication connection between the microservice 1111 and the microservice 2141 so that the microservice 2141 can provide a service related to the microservice 1111, the microservice 1111 can generate an access request used to connect to the microservice 2141. In this way, the microservice 1111 calls the microservice 2141. It can be understood that in the microservice architecture, when generating an access request, the microservice 1111 does not actually know that the microservice 1111 needs to connect to the microservice 2141, but only knows which services are required by the microservice 1111, and further adds a service to the access request or uses the service as the original destination address of the access request. After performing the service-oriented architecture management on the access request, the communication proxy can determine a target application that actually provides a service to the microservice 1111, and then forward the access request to the target application to establish a connection between the microservice 1111 and the target application.

[0111] Next, a specific data transfer path in which the microservice 1111 calls the microservice 2141 will be described with reference to FIGS. 8A, 8B, 5A, and 5B.

[0112] The microservice 1111 may generate an access request A2. The access request A2 may include a service identifier of a service that may be provided by the microservice 2141. The microservice 1111 may perform a step 801 of sending the access request A2 to the traffic blocking module 114. The traffic blocking module 114 may determine whether a service-oriented architecture management needs to be performed on the access request A2 based on the service identifier in the access request A2 by using the management mandatory list. The service identifier in the access request A2 is a service identifier corresponding to the microservice 2141, and the service identifier is in the management mandatory list. Thus, it is determined that a service-oriented architecture management needs to be performed on the access request A2. Thus, the traffic blocking module 114 may perform a step 802 of forwarding the access request A2 to the data channel 140.

[0113] The data channel 140 may perform step 803 of sending an access request A2 to the user mode protocol stack 122 .

[0114] The user mode protocol stack 122 may perform step 804 of sending the access request A2 to the communication proxy 121 .

[0115] For specific implementation of step 801, step 802, step 803, and step 804, please refer to the above description of step 701, step 702, step 703, and step 704. Details will not be repeated here.

[0116] The communication proxy 121 may perform step 805 of performing service-oriented architecture management on the access request A2. Specifically, the communication proxy 121 may perform service-oriented architecture management based on the service identifier in the access request A2 and the service-oriented architecture management policy. The service-oriented architecture management may include selecting an application that provides the service described by the service identifier of the microservice 1111 through load balancing. In this embodiment, it may be determined that the selected application that provides the service described by the service identifier of the microservice 1111 is the microservice 2141. In other words, it may be determined that the microservice 2141 is the target application of the access request A2. For example, if it is determined that the microservice 2141 is the target application of the access request A2, the socket destination address of the access request A2 may be updated to the network address of the microservice 2141. The special microservice 2141 may be referred to as the target application of the access request A2, and the network address of the special microservice 2141 may be referred to as the target application address of the access request A2. The network address of the microservice 2141 may specifically be the network address of the pod that is executing the microservice 2141, i.e., the network address of the pod 214. For example, the network address of the pod 214 may include the IP address and port number of the pod 214.

[0117] The communication proxy 121 may perform step 806 of sending the access request A2 to the user mode protocol stack 122. The user mode protocol stack 122 may perform step 807 of determining that the actual target application of the access request A2 is not located on this node. Then, the user mode protocol stack 122 may perform step 808 of adding a service mesh identifier to the access request A2. The service mesh identifier is used to indicate that the target application of the access request A2 is a microservice. The specific form of the service mesh identifier may be a customized field, number, etc. In a specific implementation, the developer or operation and maintenance personnel of the service mesh system may customize the service mesh identifier. The user mode protocol stack 122 may further perform step 809 of encapsulating the target application address of the access request A2. As described above, the target application address determined in step 805 is the network address of the microservice 2141. It may be understood that the microservice 2141 is located on a node (i.e., node 200). In step 809, the network address of the microservice 2141 may be encapsulated in the IP address of the node. For example, the network address of the microservice 2141 may be the network address of the pod 214. The network address of the pod 214 may include the IP address and port number of the pod 214. If the pod 214 is located on the node 200, in step 809, the network address of the microservice 2141 is encapsulated in the IP address of the node 200.

[0118] In addition, for the execution of steps 806, 807, 808, and 809, please refer to (3) in FIG. 5A. Specifically, in step 806, the access request A2 is used as the outbound traffic sent by the communication proxy 121 and sent to the user mode protocol stack 122. The user mode protocol stack 122 can determine that the outbound traffic is sent by the communication proxy 121 based on the UID of the data flow sending process of the access request A2, and can determine that the target application is not located on this node (node ​​100) based on the target application address of the access request A2. Then, the access request A2 can be added with a service mesh identifier, encapsulated with the target application address, etc.

[0119] Then, the user mode protocol stack 122 can execute step 810 of sending the access request A2 to the network interface card 130. See (4) in FIG. 5A. When processing traffic sent to the outside, the network interface card can directly send the traffic to the network interface card of the target node by using the network. Returning to this embodiment, see FIG. 8A. The network interface card 130 can execute step 811 of sending the access request A2 to the network interface card 230. Specifically, the network interface card 130 can send the access request A2 to the network interface card 230 by using the network 300.

[0120] See Figure 8B. The network interface card 230 may perform step 812 of recovering a target application address from the access request A2, and perform step 813 of determining that the access request A2 has a service mesh identifier. Further see (10) in Figure 5B. After receiving a data packet carrying the access request A2, the physical network interface card of the network interface card 230 may recover a target application address of the access request A2, and determine whether the access request A2 has a service mesh identifier.

[0121] Then, the network interface card 230 can execute step 814 of sending the access request A2 to the user mode protocol stack 222. Alternatively, see (12) in FIG. 5B. The network interface card 230 forwards the access request A2 to the user mode protocol stack 222 through a virtual network port between the network interface card 230 and the data card 220.

[0122] The user mode protocol stack 222 may perform step 815 of determining that the target application of the access request A2 is not a special microservice. As described above, in the initialization process, the user mode protocol stack may obtain a special microservice list. The special microservice list includes identification information of one or more special microservices. The identification information may be a network address. Thus, in step 815, the user mode protocol stack 222 may determine that the target application is not a special microservice based on the network address of the target application, i.e., the network address of the target application is not located in the special microservice list. After determining that the target application of the access request A2 is not a special microservice, the user mode protocol stack 222 may perform step 816 of sending the access request A2 to the communication proxy 221. The communication proxy 221 may again perform service-oriented architecture management on the access request A2. For example, the service data in the access request A2 is decrypted. The communication proxy 221 may then perform step 818 of sending the user mode protocol stack 222 the access request A2, on which the service-oriented architecture management is again performed. Before performing step 818, the communication proxy 221 can call an API provided by the user mode protocol stack 222 to add a service oriented architecture management identifier to the access request A2. The service oriented architecture management identifier is used to indicate that service oriented architecture management is performed on the access request A2 and the target application is deployed locally (on the node where the communication proxy 221 is located).

[0123] For the execution of steps 815 to 818, please further refer to (14) in FIG. 5B. If the user mode protocol stack 222 determines that the target application address of the access request A2 is not the address of a non-special microservice, i.e., the target application is not a special microservice, the user mode protocol stack 222 forwards the access request A2 to the listening port 3 of the communication proxy 221. The listening port 3 is the listening port for inbound traffic of the communication proxy 221. The communication proxy 221 records the access request A2 as inbound traffic and performs service-oriented architecture management on the access request A2. When the service-oriented architecture management is performed on the access request A2 and the access request A2 is sent to an upstream module or component, the API of the user mode protocol stack 222 can be called to add a service-oriented architecture management identifier to the access request A2.

[0124] The user mode protocol stack 222 may perform step 819 of transmitting the access request A2 to the data channel 240. See (15) in FIG. 5B. Upon receiving the access request A2 transmitted in step 818, the user mode protocol stack 222 may determine that the access request A2 is inbound traffic and the target application is located in the pod of this node based on the service-oriented architecture management identifier carried in the access request A2. Thus, the user mode protocol stack 222 may perform step 819 of transmitting the access request A2 to the data channel 240.

[0125] The data channel 240 may perform step 820 of sending the access request A2 to the traffic interception module 215. See (15) in FIG. 5B. Upon receiving the access request A2 sent in step 819, the end of the data channel 240 located in the data card 120 may convert the access request A2 into a data flow under the PCIe protocol and send the data flow under the PCIe protocol to the host 210. When the data flow under the PCIe reaches the end of the data channel 240 located in the host 210, the data flow under the PCIe may be converted into a socket connection request.

[0126] The traffic blocking module 215 is specifically an outbound traffic blocking module. In other words, the traffic blocking module 215 blocks or filters only traffic sent to the outside by the host 210, and does not filter traffic received from the outside by the host 210. Upon receiving the access request A2 sent in step 820, the traffic blocking module 215 can perform step 821 of sending the access request A2 to the microservice application 2141. Specifically, the access request A2 can be sent to the target application (i.e., the microservice 2141) based on the socket destination address (i.e., the network address of the microservice 2141) of the access request A2.

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

[0128] Embodiment 3: A common application on node 100 invokes a common application on node 200.

[0129] Next, with reference to FIG. 9 and FIG. 5A and FIG. 5B, an example in which the common application 113 invokes the common application 211 is used to explain the solution provided in this embodiment.

[0130] The common application 113 may generate an access request A3, and the target application address of the access request A3 is the network address of the common application 211. For example, the network address of the common application 211 may include the IP address and port number of the common application 211. See FIG. 9. The common application 113 may perform step 901 of sending the access request A3 to the traffic blocking module 114. The traffic blocking module 114 may determine that the network address of the common application is not located in the management required list, and may further perform step 902 of sending the access request A3 to the virtual network port of the host 110, so that the virtual network port of the host 110 may perform step 903 of sending the access request A3 to the network interface card 130. See further (9) of FIG. 5A. The common application 113 may send the access request A3. The traffic blocking module 114 determines that the target application of the access request A3 is the common application, and directly sends the access request to the network interface card 130 via the virtual network port.

[0131] The network interface card 130 may perform step 904 of encapsulating a target application address of the access request A3. Specifically, as shown in (5) of FIG. 5A, upon detecting that the target application of the access request A3 is located on a node other than the node 100, the network interface card 130 may encapsulate the target application address. The target application address may be encapsulated in the address of the node on which the target application is located. For example, the target application address is a network address of the common application 211, and since the common application is located on the node 200, the network address may be encapsulated in the IP address of the node 200. For example, the network address of the common application 211 may include the IP address and port number of the common application 211.

[0132] The network interface card 130 can further perform step 905 of sending the access request A3 to the network interface card 230. Specifically, see (5) in FIG. 5A. The network interface card 130 can send the access request A3 to the network 300 by using a physical network interface card, and then the network 300 can forward the access request A3 to the network interface card 230 based on the destination address of the access request A3 (i.e., the address obtained after encapsulation in step 904).

[0133] After receiving the access request A3, the network interface card 230 may perform step 906 of recovering the target application address of the access request A3. That is, in step 906, the target application address encapsulated in step 904 may be recovered.

[0134] The network interface card 230 may perform step 907 of determining that the access request A3 does not have a service mesh identifier. It will be understood that the service request A3 does not pass through the data card 120 and therefore does not have a service mesh identifier. The network interface card 230 may further perform step 908 of determining that the target application address is not a service mesh gateway address. The service mesh gateway address is the address of the listening port of the communication proxy. For example, the listening port 3 of FIG. 5B may be used as the service mesh gateway address of the node 200. The network interface card 230 may then perform step 909 of sending the access request A3 to the virtual network port of the host 210. The virtual network port of the host 210 may perform step 910 of sending the access request A3 to the traffic blocking module 215. The traffic blocking module 215 may perform step 911 of sending the access request A3 to the common application 211.

[0135] For the execution of steps 907 to 911, please further refer to (11) in FIG. 5B. If the network interface card 230 can determine that the access request A3 does not have a service mesh identifier and the target application address is not a service mesh gateway address, the network interface card 230 can forward the access request A3 to the host 210 through a virtual network port. Then, the system kernel of the host 210 may directly send the access request A3 to the common application 211.

[0136] Therefore, a connection between the common application 113 and the common application 211 may be established, and the common application 113 may call the common application 211. For example, the access request A3 may specifically be a socket connection request, and the connection established between the common application 113 and the common application 211 may be a socket connection.

[0137] Example 4: A microservice on node 100 invokes a special microservice on node 200.

[0138] A special microservice generally includes, but is not limited to, an application that can be connected without going through a second communication proxy (e.g., a sidecar). In other words, an access request whose target application is a special microservice can reach the target application without undergoing a second service-oriented architecture management, thereby implementing the connection between the source application and the target application. The source application is an application that generates the access request. Typical special microservices include a microservice that provides a traffic restriction service, a microservice that provides a data collection service, etc.

[0139] In a scenario of invoking a special microservice, when an access request initiated by a microservice in the user space of the host passes through the communication proxy for the first time, the communication proxy needs to actively invoke the special microservice to perform service-oriented architecture management on the access request. For example, the communication proxy can invoke a microservice providing a traffic limiting service to determine whether the access request exceeds a traffic limiting threshold. If the access request exceeds the traffic limiting threshold, the communication proxy can return a failure response to the microservice that initiated the access request. When the access request passes through the communication proxy for the first time, the communication proxy can further invoke a data collection service to report the collected link call data to the data collection service to create a network call topology diagram.

[0140] Because the special microservice is a microservice in the service mesh, it is difficult to configure a blocking solution in the network interface card that is used to block an access request whose target application is the special microservice. As a result, the access request for which service-oriented architecture management is performed for the first time may be sent to the communication proxy again, causing unnecessary service-oriented architecture management. To solve this problem, in this embodiment, whether the target application of the access request is a special microservice can be determined by using a special microservice list in the user mode protocol stack, so that if the target application of the access request is not a special microservice, the access request can be sent directly to the host without passing through the communication proxy for a second time.

[0141] Next, referring to Figures 10A, 10B, 5A, and 5B, an example in which a microservice 1111 on a node 100 calls a special microservice 2131 on a node 200 is used to explain the solution in this embodiment.

[0142] The microservice 1111 may generate an access request A4. The access request A4 may include a service identifier of a service that may be provided by the special microservice 2131. The microservice 1111 may perform a step 1001 of sending the access request A4 to the traffic blocking module 114. The traffic blocking module 114 may determine whether a service-oriented architecture management needs to be performed on the access request A4 based on the service identifier in the access request A4 by using the management mandatory list. The service identifier in the access request A4 is a service identifier corresponding to the special microservice 2131, and the service identifier is located in the management mandatory list. Thus, it is determined that a service-oriented architecture management needs to be performed on the access request A4. Thus, the traffic blocking module 114 may perform a step 1002 of forwarding the access request A4 to the data channel 140.

[0143] The data channel 140 may perform step 1003 of sending an access request A4 to the user mode protocol stack 122 .

[0144] The user mode protocol stack 122 may execute step 1004 of sending an access request A4 to the communication proxy 121 .

[0145] For specific implementation of step 1001, step 1002, step 1003, and step 1004, please refer to the above description of step 701, step 702, step 703, and step 704. Details will not be repeated here.

[0146] The communication proxy 121 may execute step 1005 of performing service-oriented architecture management on the access request A4. Specifically, the communication proxy 121 may execute service-oriented architecture management based on the service identifier in the access request A4 and the service-oriented architecture management policy. The service-oriented architecture management may include selecting an application that provides the service described by the service identifier of the microservice 1111 through load balancing. In this embodiment, the selected application that provides the service described by the service identifier of the microservice 1111 may be determined to be the special microservice 2131. That is, the special microservice 2131 may be determined to be the target application of the access request A4. For example, if it is determined that the special microservice 2131 is the target application of the access request A4, the socket destination address of the access request A4 may be updated to the network address of the special microservice 2131. The special microservice 2131 may be referred to as the target application of the access request A4, and the network address of the special microservice 2131 may be referred to as the target application address of the access request A4. The network address of the particular microservice 2131 may be the network address of the pod running the particular microservice 2131, i.e., the network address of the pod 213. For example, the network address of the pod 213 may include the IP address and port number of the pod 213.

[0147] The communication proxy 121 may execute step 1006 of sending the access request A4 to the user mode protocol stack 122. The user mode protocol stack 122 may execute step 1007 of determining that the target application of the access request A4 is not located on this node. The user mode protocol stack 122 may then execute step 1008 of adding a service mesh identifier to the access request A4. For the service mesh identifier, please refer to the above description of the embodiment shown in FIG. 8A and FIG. 8B. Details will not be repeated here. The user mode protocol stack 122 may further execute step 1009 of encapsulating the target application address of the access request A4. As described above, the target application address determined in step 1005 is the network address of the special microservice 2131. It will be understood that the special microservice 2131 is located on a node (i.e., node 200). In step 1009, the network address of the special microservice 2131 may be encapsulated into the address of the node. For example, the network address of the particular microservice 2131 may include the network address of the pod 213. The pod 213 is located on the node 200. In step 1009, the network address of the particular microservice 2131 may be encapsulated in the IP address of the node 200.

[0148] In addition, for the execution of steps 1006, 1007, 1008, and 1009, please refer to (3) in FIG. 5A. Specifically, in step 1006, the access request A4 is used as the outbound traffic sent by the communication proxy 121 and sent to the user mode protocol stack 122. The user mode protocol stack 122 can determine that the outbound traffic is sent by the communication proxy 121 based on the UID of the data flow sending process of the access request A4, and can determine that the target application is not located on this node (node ​​100) based on the target application address of the access request A4. Then, the access request A4 can be added with a service mesh identifier, encapsulated with the target application address, etc.

[0149] Then, the user mode protocol stack 122 can execute step 1010 of sending the access request A4 to the network interface card 130. See (4) in FIG. 5A. When processing traffic sent to the outside, the network interface card can directly send the traffic to the network interface card of the target node by using the network. Returning to this embodiment, see FIG. 10A. The network interface card 130 can execute step 1011 of sending the access request A4 to the network interface card 230. Specifically, the network interface card 130 can send the access request A4 to the network interface card 230 by using the network 300.

[0150] See Figure 10B. The network interface card 230 can perform step 1012 of recovering a target application address from the access request A4, and perform step 1013 of determining that the access request A4 has a service mesh identifier. Further see (10) in Figure 5B. After receiving a data packet carrying the access request A4, the physical network interface card of the network interface card 230 can recover a target application address of the access request A4 and determine whether the access request A4 has a service mesh identifier.

[0151] Then, the network interface card 230 can execute step 1014 of sending the access request A4 to the user mode protocol stack 222. Alternatively, see (12) in FIG. 5B. The network interface card 230 forwards the access request A4 to the user mode protocol stack 222 through a virtual network port between the network interface card 230 and the data card 220.

[0152] The user mode protocol stack 222 may perform step 1015 of determining that the target application of the access request A4 is a special microservice. As described above, in the initialization process, the user mode protocol stack may obtain a special microservice list. The special microservice list includes identification information of one or more special microservices. The identification information may be a network address. Thus, in step 1015, the user mode protocol stack 222 may determine that the target application is a special microservice based on the network address of the target application, i.e., the network address of the target application is located in the special microservice list.

[0153] After determining that the target application of the access request A4 is the special microservice, the user mode protocol stack 222 may perform step 1016 of sending the access request A4 to the data channel 240. The data channel 240 may perform step 1017 of sending the access request A4 to the traffic blocking module 215. The traffic blocking module 215 may perform step 1018 of sending the access request A4 to the special microservice 2131.

[0154] For the execution of steps 1016 to 1018, please refer to (13) in FIG. 5B. After determining that the target application of the access request A4 is the special microservice 2131, the user mode protocol stack 222 can directly send the access request A4 to the data channel 240. When the access request A4 is a socket connection request and the end of the data channel 240 located at the data card 120 receives the access request A4, the end can convert the access request A4 into a data flow under the PCIe protocol and send the data flow under the PCIe protocol to the host 210. When the data flow under the PCIe reaches the end of the data channel 240 located at the host 210, the data flow under the PCIe may be converted into the access request A4 in the form of a socket connection request. The system kernel of the host 210 may directly send the access request A4 to the special microservice 2131.

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

[0156] Embodiment 5: A common application on a node 200 invokes another common application on the node 200.

[0157] Next, with reference to FIG. 11 and FIG. 5A and FIG. 5B, an example in which a common application 212 invokes a common application 211 will be used to explain the solution provided in this embodiment.

[0158] See Figure 11. The common application 212 can generate an access request A5, and a target application address of the access request A5 is a network address of the common application 211. The common application 212 can perform step 1101 of sending the access request A5 to the traffic blocking module 215. The traffic blocking module 215 can determine that the target application of the access request A5 is the common application 211. The traffic blocking module 215 can perform step 1102 of sending the access request A5 to the common application 211.

[0159] See (17a) in Figure 5B. The target application of the access request initiated by the common application 212 is the common application 211. The traffic interception module 215 in the system kernel of the host 210 can determine that the target application to which the common application 212 requests to connect is the common application 211 on the local host, and can further directly send the access request initiated by the common application 212 to the common application 211.

[0160] Therefore, a connection between the common application 212 and the common application 211 may be established, and the common application 212 may call the common application 211 .

[0161] Embodiment 6: The node 200 forwards the access request of the node 100.

[0162] The service mesh system may further include a node 500. Due to network limitations, there is no direct communication connection between the node 100 and the node 500. As a result, it is difficult to directly send an access request sent by a microservice on the node 100 to the node 500. In this case, when the microservice on the node 100 needs to call an application (which may be a microservice or a common application) on the node 500, the node 200 can forward the access request sent by the node 500 to the node 100. In other words, the node 200 can provide a relay service to act as a relay node between the node 100 and the node 500. The relay service is a service in the service mesh. In other words, the relay service may be provided by one or more microservices. In one example, the relay service may be specifically provided by a communication proxy in the node.

[0163] Next, with reference to Figures 12A, 12B, 5A, and 5B, the solution provided in this embodiment will be described using an example in which the microservice 1111 calls a service on the node 500.

[0164] The microservice 1111 may generate an access request A6 that is used to request an application on the node 500 to be invoked. For ease of explanation, the application on the node 500 that is requested to be invoked by the access request A6 may be referred to as application B. If there is no direct communication connection between the node 100 and the node 500 and the access request A6 is a socket connection request, the microservice 1111 encapsulates the network address of the application B in the header of the layer C1 of the access request A6 and uses the service identifier of the relay service as the destination address of the layer C2 of the access request A6. The destination address in the layer C2 is the direct address of the access request A6, and a module or component on the forwarding path of the access request A6 can directly identify the destination address in the layer C2 and route the access request A6 based on the destination address. In a service mesh system, when the microservice 1111 generates an access request, it is in the layer C2, and it will be understood that the destination address set by the microservice 1111 for the access request is a service identifier and not the address of a specific module or component. The service identifier is used to identify that a service-oriented architecture management needs to be performed on the access request so that the access request can be forwarded to a communication proxy based on a destination address in layer C2. For example, layer C2 may be a transport layer or a fourth layer of a network 7-layer protocol. Layer C1 is a layer above layer C2. For example, layer C1 may be an application layer or a seventh layer in a network 7-layer protocol.

[0165] The microservice 1111 may execute step 1201 of sending the access request A6 to the traffic blocking module 114. The traffic blocking module 114 may determine that a destination address in the transport layer of the access request A6, i.e., a service identifier of the relay service, is located in a management required list to determine that service-oriented architecture management needs to be performed on the access request A6.

[0166] The traffic blocking module 114 may perform a step 1202 of forwarding the access request A6 to the data channel 140. The data channel 140 may perform a step 1203 of sending the access request A6 to the user mode protocol stack 122. The user mode protocol stack 122 may perform a step 1204 of sending the access request A6 to the communication proxy 121.

[0167] For specific implementation of steps 1201, 1202, 1203, and 1204, please refer to the above description of steps 701, 702, 703, and 704, and the above description of (1) and (2) in FIG. 5A. Details will not be repeated here.

[0168] The communication proxy 121 may execute step 1205 of performing service-oriented architecture management on the access request A6. Specifically, the communication proxy 121 may execute a service-oriented architecture gateway based on the service identifier in the layer C1 in the access request A6 and the service-oriented architecture management policy to determine an application that provides a relay service for the access request A6. For example, in step 1205, the communication proxy 221 in the node 200 may be set to determine that it provides a relay service for the access request A6. In other words, it is determined that the communication proxy 221 is the target application of the access request A6, and the network address of the communication proxy 221 is the target application address of the access request A6. Then, the communication proxy 121 may update the destination address of the layer C2 of the access request A6 to the network address of the communication proxy 221. For example, the network address of the communication proxy 221 may specifically be the network address of the listening port 3. The communication proxy 121 may send the updated access request A6 to the user mode protocol stack 122 in step 1206.

[0169] The user mode protocol stack 122 may perform step 1207 of determining that the target application of the access request A6 is not located on this node. The user mode protocol stack 122 may perform step 1208 of adding a service mesh identifier to the access request A6 and perform step 1209 of encapsulating the target application address of the access request A6. Specifically, the network address of the communication proxy 221 may be encapsulated in the IP address of the node 200. The user mode protocol stack 122 may further perform step 1210 of sending the access request A6 with the encapsulated address to the network interface card 130. The network interface card 130 may perform step 1211 of sending the access request A6 to the network interface card 230.

[0170] The network interface card 230 may perform step 1212 of recovering the target application address of the access request A6 and may perform step 1213 of determining that the access request A6 has a service mesh identifier. The network interface card 230 may then perform step 1214 of sending the access request A6 to the user mode protocol stack 222.

[0171] The user mode protocol stack 222 may perform step 1215 of determining that the target application of the access request A6 is not a special microservice. Then, in step 1216, the user mode protocol stack 222 may send the access request A6 to the communication proxy 221.

[0172] For specific implementation of steps 1205 to 1216, please refer to the above description of steps 805 to 816 in Figures 8A and 8B and (2), (3), (4), (10), (12), and (14) in Figures 5A and 5B. Details will not be repeated here.

[0173] Continuing to refer to FIG. 12B, the communication proxy 221 may execute step 1217 of parsing the header of layer C1 of the access request A6 to obtain the network address of application B. The communication proxy 221 may skip executing the service-oriented architecture management for the access request A6, but executes step 1218 of updating the target application address of the access request A6 to the network address of application B. In other words, the target application of the access request A6 is updated to application B. Then, step 1220 of sending the updated access request A6 to the user mode protocol stack 222 may be executed. For example, in step 1220, the communication proxy 221 may call the API of the user mode protocol stack 222 to add a service-oriented architecture management identifier to the access request A6.

[0174] For the execution of steps 1217 to 1220, see (15) in FIG. 5B. The communication proxy 221 records the access request A6 as inbound traffic, and can determine that the node 200 is a relay node of the access request A6 based on the contents in the data packet of the access request A6 (i.e., the contents of the layer C1). In this way, the communication proxy 221 skips the subsequent service-oriented architecture management, updates the target application address of the access request A6 to the address of the application B, and calls the API of the user mode protocol stack 222 to add a service-oriented architecture management identifier to the access request A6 because the access request A6 is inbound traffic.

[0175] The user mode protocol stack 222 may perform step 1221 of determining that the target application of the access request A6 is not located on this node (node ​​200) and perform step 1222 of encapsulating the target application address of the access request A6. For example, the network address of application B may be encapsulated into the IP address of node 500. In one example, if application B is a microservice, the user mode protocol stack 222 may further add a service mesh identifier to the access request A6. Then, in step 1223, the user mode protocol stack 222 may send the access request A6 to the network interface card 230. The network interface card 230 may perform step 1224 of sending the access request A6 to the node 500.

[0176] For the execution of steps 1221 to 1224, see (16) in FIG. 5B. The user mode protocol stack 222 may determine that the target application of the access request A6 is not located on this node, and may determine that the access request A6 is an inbound traffic based on the service-oriented architecture management identifier of the access request A6. In this case, the user mode protocol stack 222 may add a service mesh identifier to the access request A6, encapsulate the target application address, and then transmit the access request A6 to the network 300 by using the network interface card 230 to transmit the access request A6 to the node 500 by using the network 300.

[0177] According to the aforementioned solution, when there is no direct communication connection between a node and another node, the other node may be used as a relay node to implement indirect communication between the nodes.

[0178] Example 7: A common application on node 100 invokes a microservice on node 200.

[0179] In a scenario where a common application needs to call a microservice, the communication proxy can be configured as an inbound gateway. The inbound gateway can also be called a service mesh gateway. When the destination address of the access request is a service mesh gateway address, the network interface card can send the access request to the data card even if the access request does not include a service mesh identifier, so that the data card performs service-oriented architecture management on the access request and sends the access request to the corresponding microservice. In this way, the common application calls the microservice.

[0180] Next, with reference to Figures 13A, 13B, 5A, and 5B, a solution in which a common application calls a microservice provided in this embodiment will be described using an example in which a common application 113 calls a microservice 2141.

[0181] The common application 113 may generate an access request A7 using the service mesh gateway address of the node 200 as an initial destination address. The service request A7 may further include a service identifier of the service required by the common application 113. For the service identifier, please refer to the above description. Details will not be repeated here. For example, the access request A7 may be a data packet, and the service identifier may be encapsulated in the application layer header of the data packet. In addition, it will be understood that the destination address of the access request A7 is usually located at the transport layer.

[0182] The common application 113 can execute step 1301 of sending an access request A7 to the network interface card 130. See (5) of FIG. 5A. When the access request A7 passes through the traffic blocking module 114, the traffic blocking module 114 determines that the initial destination address of the access request A7 is not in the management required list. For example, the initial destination address of the access request A7 may be an address located at the transport layer. That is, the traffic blocking module 114 determines that the transport layer address of the access request A7 is not in the management required list. Furthermore, the traffic blocking module 114 can send the access request A7 to the network interface card 130 through a virtual network port.

[0183] The network interface card 130 may perform step 1302 of encapsulating an initial destination address of the access request A7. For example, the service mesh gateway address used as the initial destination address may be the network address of the listening port of the communication proxy 221. The network address of the listening port may be encapsulated into the IP address of the node 200.

[0184] The network interface card 130 may execute step 1303 of sending the access request A7, in which its initial destination address is encapsulated, to the network interface card 230. For details, see (10) in FIG. 5B. In step 1303, the access request A7 may enter the network 300 through the physical network interface card of the network interface card 130, and may be received by the physical network interface card of the network interface card 230 after being forwarded by the network 300.

[0185] The network interface card 230 may perform step 1304 of restoring the initial destination address of the access request A7. That is, the service mesh gateway address is restored. The network interface card 230 may perform step 1305 of sending the access request A7 to the user mode protocol stack 222. See (17b) and (12) in FIG. 5B. The network interface card 230 may determine that the initial destination address of the access request A7 is the service mesh gateway address. If the initial destination address of the access request A7 is the service mesh gateway address, the network interface card 230 may send the access request A7 to the user mode protocol stack 222 through the virtual network port even if the access request A7 does not have a service mesh identifier.

[0186] The user mode protocol stack 222 may perform step 1306 of determining that the initial destination address of the access request A7 is a service mesh gateway address, and then perform step 1307 of sending the access request A7 to the communication proxy 221. For example, see (14) in FIG. 5B. The initial destination address may be specifically set to the network address of the listening port 3 of the communication proxy 221. If it is determined that the initial destination address is not the address of a special microservice and the access request A7 does not have a service mesh identifier, the user mode protocol stack 222 may send the access request A7 to the listening port 3 of the communication proxy 221.

[0187] The communication proxy 221 may perform step 1308 of determining the service actually requested by the access request A7. As described above, the access request A7 carries a service identifier, and the service identifier is used to indicate the service requested by the common application 113. The service identifier may be in an application layer header of the access request A7. The communication proxy 221 may parse the access request A7, for example, parse the application layer header of the access request A7, to obtain the service identifier. After obtaining the service identifier, the communication proxy 221 may perform step 1309 of performing service-oriented architecture management on the access request A7. Specifically, the microservice used to provide the service indicated by the service identifier may be determined based on the service identifier by using a service list and a service-oriented architecture management policy. In this embodiment, it may be determined that the microservice 2141 is used to provide the service indicated by the service identifier. Then, the communication proxy 221 may perform step 1310 of sending the access request A7 to the user mode protocol stack 222. For the execution of steps 1308 to 1310, see (14) in FIG. 5B. When the communication proxy 221 receives the access request A7 via the listening port 3, it can record the access request A7 as inbound traffic. After the service-oriented architecture management is performed on the access request A7, when the access request A7 is sent to an upstream module or component, an API of the user mode protocol stack 222 can be called to add a service-oriented architecture management identifier to the access request A7.

[0188] In this embodiment, the service identifier of the service may be referred to as the service identifier for short.

[0189] The user mode protocol stack 222 can execute step 1311 of sending the access request A7 to the microservice 2141. For the specific process of step 1311, please refer to the above description of steps 819 to 821 in FIG. 8B. Details will not be repeated here.

[0190] Therefore, a connection between the common application 113 and the microservice 2141 may be established, and the common application 113 may call the microservice 2141. For example, the access request A7 may specifically be a socket connection request, and the connection established between the common application 113 and the microservice 2141 may be a socket connection.

[0191] Example 8: A microservice on node 100 invokes a common application on node 200.

[0192] Some common applications in a service mesh system may be invoked by microservices. In this embodiment, service identifiers of services provided by these common applications may be predefined to enable these common applications to be invoked by microservices. Service C is used as an example. The service identifier of service C may be information describing or indicating service C. Service C may be provided by a common application. The service identifiers of services provided by these common applications may be set in a management required list. In this embodiment, for ease of explanation, the service identifiers of services provided by the common application may be referred to as the service identifiers of the common application. For example, the service identifier of the common application may be a network address of the common application. In one example, the network address of the common application may include an IP address and a port number of the common application.

[0193] As described above, the management must-know list may be pre-configured by a developer or an operation and maintenance personnel of the service mesh system. Once the management must-know list is configured, a service identifier of a common application that may be invoked by a microservice may be added to the management must-know list. If the management must-know list includes a service identifier of the common application, an access request carrying the service identifier of the common application may be sent to the data card to accept the service-oriented architecture management of the communication proxy. Thus, the service identifier of the common application is used to declare that service-oriented architecture management must be performed on the access request.

[0194] In some embodiments, the service list may also include a correspondence between the service identifier and the network address of the common application, so that the communication proxy can determine the accessible network address based on the service identifier. The service list includes a type of application corresponding to the network address, and the type of application may be classified into a microservice and a common application. Specifically, the service list records whether the application corresponding to the network address is a microservice or a common application.

[0195] For specific configuration methods of the management required list and the service list, please refer to the above description of the embodiment shown in Figure 6. Details will not be repeated here.

[0196] Next, with reference to Figures 14A, 14B, 5A, and 5B, an example in which a microservice 1111 calls a common application 211 will be used to describe a solution in which a microservice calls a common application provided in this embodiment.

[0197] When microservice 1111 needs to use a service provided by common application 211, microservice 1111 can generate access request A8 and use the service's service identifier as the initial destination address of access request A8.

[0198] The microservice 1111 may execute step 1401 of sending the access request A8 to the traffic blocking module 114. The traffic blocking module 114 may determine that the initial destination address of the access request A8 or the service identifier carried in the access request A8 is in the management required list, and the traffic blocking module 114 may execute step 1402 of sending the access request A8 to the data channel 140. The data channel 140 may execute step 1403 of sending the access request A8 to the user mode protocol stack 122. The user mode protocol stack 122 may execute step 1404 of sending the access request A8 to the communication proxy 121. For the execution of steps 1401 to 1404, please refer to the above description of steps 701 to 704 in FIG. 7 and (1) and (2) in FIG. 5A. Details will not be repeated here.

[0199] The communication proxy 121 may execute step 1405 of performing service-oriented architecture management on the access request A8. The service-oriented architecture management may include determining an application that can provide the service described by the service identifier based on the service identifier carried in the access request A8 by using a service list and based on a load balancing policy. The determined application may be set to the common application 211. After step 1405, the network address of the common application 211 is determined as a target application address of the access request A8, and correspondingly, the common application 211 is determined as a target application of the access request A8.

[0200] The communication proxy 121 may perform step 1406 of adding a non-service mesh identifier to the access request A8. The non-service mesh identifier is used to indicate that the target application of the access request carrying the non-service mesh identifier is not a microservice. As described above, the service list records the type of application corresponding to the network address. When it is determined that the network address of the common application 211 is determined as the target application address of the access request A8, it may be determined that the target application of the access request A8 is a common application rather than a microservice in the service mesh. Thus, the non-service mesh identifier may be added to the access request A8. For example, the communication proxy 121 may call an API to add the non-service mesh identifier to the access request A8.

[0201] After performing step 1406 , the communication proxy 121 may perform step 1407 of sending an access request A 8 to the user mode protocol stack 122 .

[0202] The user mode protocol stack 122 may perform step 1408 of determining that the target application of the access request A8 is not located on this node and determining that the access request A8 has a non-service mesh identifier. The user mode protocol stack 122 may then perform step 1409 of encapsulating the target application address of the access request A8. Specifically, the target application address of the access request A8 may be encapsulated in the IP address of the node 200.

[0203] The user mode protocol stack 122 may then send the access request A8 to the network interface card 130. Upon receiving the access request A8, the network interface card 130 may perform step 1411 of sending the access request A8 to the network interface card 230.

[0204] Upon receiving the access request A8, the network interface card 230 may perform step 1412 of recovering a target application address of the access request A8. Step 1413 and step 1414 may be further performed. In step 1413, it may be determined that the access request A8 does not have a service mesh identifier, and it may be determined that the access request A8 has a non-service mesh identifier. In step 1414, it is determined that the target application address of the access request A8 is not a service mesh gateway address. Therefore, the network interface card 230 may perform step 1415 of directly sending the access request A8 to the common application 211.

[0205] See (11) in Figure 5B. If A8 does not have a service mesh identifier and the target application address of the access request A8 is not a service mesh gateway address, the network interface card 230 no longer sends the access request A8 to the data card 220, but directly sends the access request A8 to the host 210 via a virtual network port, so that the host 210 can directly send the access request A8 to the common application 211.

[0206] Therefore, a connection between the microservice 1111 and the common application 211 is established, and the microservice 1111 invokes the common application 211. For example, the access request A8 may specifically be a socket connection request, and the connection established between the microservice 1111 and the common application 211 may be a socket connection.

[0207] As can be seen from the above description, in this embodiment of the present application, the sidecar may be deployed in the data card, so that the service calls in the service mesh can be synced to the data card for processing and transmission. Therefore, the computing resources of the host are not further occupied, the service-oriented architecture management efficiency is improved, and the computing resources of the host are saved. In addition, the client application can be applied to the service mesh system provided in this embodiment of the present application without being reconstructed. Therefore, the service mesh system is highly useful.

[0208] In relation to the above embodiment, an embodiment of the present application further provides a service mesh system. As shown in Fig. 4, the service system may include a node 100. The node 100 includes a host 110 and a data card 120. The data card 120 is inserted into the host 110. A data channel 140 is established between the data card 120 and the host 110. A first pod runs on the host 110. A first microservice is provided in the first pod. The data card 120 accesses a network 300.

[0209] By using the network 300, the data card 120 can receive the service-oriented architecture management policy sent by the management and control node, and perform service-oriented architecture management on the first access request sent by the host 110 to the data card 120 through the data channel 140 based on the service-oriented architecture management policy. The first access request is an access request of the first microservice to the second microservice, and is obtained by the host 110 from the first pod. For details, please refer to the above description of the embodiment shown in Figures 5A and 5B, 6, and 7. Details will not be repeated here.

[0210] In some embodiments, the service-oriented architecture management policy includes a correspondence between the second microservice and a network address of a second pod that runs the second microservice. The data card 120 is configured to determine the network address of the second pod that runs the second microservice based on the service-oriented architecture management policy, set the destination address of the first access request to the network address of the second pod, determine that the second pod is located on the host 110, and send the modified first access request to the second pod through the data channel 140. For details, please refer to the above description of embodiment 1. Details will not be repeated here.

[0211] In some embodiments, the service-oriented architecture management policy further includes a correspondence between the third microservice and a network address of a third pod that runs the third microservice. The host 110 is further configured to obtain a second access request of the first microservice for the third microservice from the first pod, and send the second access request to the data card 120 through the data channel 140. The data card 120 is configured to determine a network address of a third pod that runs the third microservice based on the service-oriented architecture management policy, set a destination address of the second access request to the network address of the third pod, determine that the third pod is not located on the host 110, and send the second access request by using a network. For details, please refer to the above description of embodiment 2. Details will not be repeated here.

[0212] In one example of these embodiments, the node 100 further includes a network interface card 130. The network interface card 130 is connected to the data card 120. The data card 120 accesses the network by using the network interface card 130. The data card 120 is configured to send a second access request to the network interface card 130. The network interface card 130 is configured to send the second access request by using the network. For details, please refer to the above description of embodiment 2. Details will not be repeated here.

[0213] In one example of this example, see FIG. 4. The service mesh system further includes a node 200. The node 200 includes a host 210, a data card 220, and a network interface card 230. The data card 220 is inserted into the host 210. A data channel 240 is established between the data card 220 and the host 210. A third pod runs on the host 210. The network interface card 230 is connected to the data card 220. The network interface card 230 accesses the network. The data card 120 is further configured to set a service mesh identifier for the second access request if it determines that the third pod is not located on the host 110. The network interface card 230 is configured to receive the second access request sent by the network interface card 130, and send the second access request to the data card 220 if it determines that the second access request carries a service mesh identifier. When the data card 220 determines that the third pod is disposed in the host 210, the data card 220 is configured to send a second access request to the third pod via the data channel 240. For details, please refer to the above description of the second embodiment. Details will not be repeated here.

[0214] In some embodiments, the service mesh system further includes a node 200. The node 200 includes a host 210. The host 210 and the host 110 access the network. The first application runs on the host 110. The second application runs on the host 210. The host 110 is configured to obtain a third access request of the first application for a network address of the second application, and transmit the third access request by using the network when the host 110 determines that the second application is not running on the host 110. The host 210 is configured to receive the third access request transmitted by the host 110 and transmit the third access request to the second application. For details, please refer to the above description of the third embodiment. Details will not be repeated here.

[0215] In some embodiments, the first application and the second application run on the host 110. The host 110 is configured to obtain the third access request of the first application for the network address of the second application, and send the third access request to the second application when it determines that the second application runs on the host 110. For details, please refer to the above description of embodiment 5. Details will not be repeated here.

[0216] In some embodiments, the service mesh system further includes a node 200. The node 200 includes a host 210 and a data card 220. The data card 220 is inserted into the host 210. A data channel 240 is established between the data card 220 and the host 210. A fourth pod runs on the host 210. A fourth microservice is provided in the fourth pod. The data card 220 and the host 110 access a network. The first application runs on the host 110. The host 110 is configured to obtain a fourth access request of the first application for a network address of the data card 220 and send the fourth access request by using the network. The data card 220 is configured to receive the fourth access request sent by the host 110 and send the fourth access request to the fourth microservice via the data channel 240 based on an identifier carried in the fourth access request, which is of the fourth microservice. For details, please refer to the above description of embodiment 7. The details will not be repeated here.

[0217] In some embodiments, the service mesh system further includes a node 200. The node 200 includes a host 210. The third application runs on the host 210. The host 210 accesses a network. The host 110 is configured to obtain a fifth access request of the first microservice for the network address of the third application, and send the fifth access request to the data card 120 through the data channel 140. The data card 120 is configured to send the fifth access request by using the network. The host 210 is configured to receive the fifth access request and send the fifth access request to the third application. For details, please refer to the above description of embodiment 8. Details will not be repeated here.

[0218] Please refer to Figure 15. An embodiment of the present application provides a data processing method. The method may be applied to the service mesh system shown in Figure 4. As shown in Figure 15, the method includes the following steps:

[0219] Step 1501: The data card 120 receives a service-oriented architecture management policy sent by a management and control node by using a network.

[0220] Step 1502: The data card 120 performs service-oriented architecture management on a first access request sent by the host 110 to the data card 120 through the data channel 140 based on a service-oriented architecture management policy. The first access request is an access request of the first microservice for the second microservice and is obtained by the host 110 from the first pod.

[0221] For details, please refer to the above description of the embodiments shown in Figures 5A and 5B, 6, and 7. The details will not be repeated here.

[0222] In some embodiments, the service-oriented architecture management policy includes a correspondence between the second microservice and a network address of a second pod that runs the second microservice. Step 1502 includes the data card 120 determining the network address of the second pod that runs the second microservice based on the service-oriented architecture management policy, and setting the destination address of the first access request to the network address of the second pod. The data card 120 determines that the second pod is located on the host 110, and sends the modified first access request to the second pod via the data channel 140. For details, please refer to the above description of embodiment 1. Details will not be repeated here.

[0223] In some embodiments, the service-oriented architecture management policy further includes a correspondence between the third microservice and a network address of a third pod that runs the third microservice. The method further includes the host 110 obtaining a second access request of the first microservice for the third microservice from the first pod, and sending the second access request to the data card 120 through the data channel 140. The data card 120 determines a network address of a third pod that runs the third microservice based on the service-oriented architecture management policy, and sets a destination address of the second access request to the network address of the third pod. The data card 120 determines that the third pod is not located on the host 110, and sends the second access request by using a network. For details, please refer to the above description of embodiment 2. Details will not be repeated here.

[0224] In one example of these embodiments, the node 100 further includes a network interface card 130. The network interface card 130 is connected to the data card 120. The data card 120 accesses the network by using the network interface card 130. The data card 120 determining that the third pod is not located on the host 110 and sending a second access request by using the network includes the data card 120 determining that the third pod is not located on the host 110 and sending a second access request to the network interface card 130. The network interface card 130 sends the second access request by using the network. For details, please refer to the above description of embodiment 2. Details will not be repeated here.

[0225] In one example of this example, the service mesh system further includes a node 200. The node 200 includes a host 210, a data card 220, and a network interface card 230. The data card 220 is inserted into the host 210. A data channel 240 is established between the data card 220 and the host 210. A third pod operates on the host 210. The network interface card 230 is connected to the data card 220. The network interface card 230 accesses the network. The method further includes the data card 120 setting a service mesh identifier of the second access request when it is determined that the third pod is not located on the host 110. The network interface card 230 receives the second access request sent by the network interface card 130, and sends the second access request to the data card 220 when it is determined that the second access request carries a service mesh identifier. When the data card 220 determines that the third pod is disposed on the host 210, it sends a second access request to the third pod via the data channel 240. For details, please refer to the above description of the second embodiment. Details will not be repeated here.

[0226] In some embodiments, the service mesh system further includes a node 200. The node 200 includes a host 210. The host 210 and the host 110 access the network. The first application runs on the host 110. The second application runs on the host 210. The method further includes:

[0227] The host 110 obtains the third access request of the first application for the network address of the second application, and when it determines that the second application is not running on the host 110, sends the third access request by using the network. The host 210 receives the third access request sent by the host 110, and sends the third access request to the second application. For details, please refer to the above description of embodiment 3. Details are not repeated here.

[0228] In some embodiments, the first application and the second application run on the host 110. The method further includes: when the host 110 obtains a third access request of the first application for the network address of the second application and determines that the second application runs on the host 110, the host 110 sends the third access request to the second application. For details, please refer to the above description of embodiment 5. Details will not be repeated here.

[0229] In some embodiments, the service mesh system further includes a node 200. The node 200 includes a host 210 and a data card 220. The data card 220 is inserted into the host 210. A data channel 240 is established between the data card 220 and the host 210. A fourth pod runs on the host 210. A fourth microservice is provided in the fourth pod. The data card 220 and the host 110 access a network. The first application runs on the host 110. The method further includes the host 110 obtaining a fourth access request of the first application for a network address of the data card 220, and sending the fourth access request by using the network. The data card 220 receives the fourth access request sent by the host 110, and sends the fourth access request to the fourth microservice through the data channel 240 based on an identifier carried in the fourth access request, which is of the fourth microservice. For details, please refer to the above description of embodiment 7. The details will not be repeated here.

[0230] In some embodiments, the service mesh system further includes a node 200. The node 200 includes a host 210. The third application runs on the host 210. The host 210 accesses the network. The method further includes the host 110 obtaining a fifth access request of the first microservice for the network address of the third application, and sending the fifth access request to the data card 120 through the data channel 140. The data card 120 sends the fifth access request by using the network. The host 210 receives the fifth access request and sends the fifth access request to the third application. For details, please refer to the above description of embodiment 8. Details will not be repeated here.

[0231] Please refer to Figure 16. An embodiment of the present application further 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 in Figure 16, the data card 1620 is inserted into the host 1610 by using a PCIe interface.

[0232] The host 1610 may include a processor 1611 and a memory 1612. The memory 1612 may store computer instructions, which may be executed by the processor 1611. The data card 1620 may include a processor 1621 and a memory 1622. The memory 1622 may store computer instructions, which may be executed by the processor 1621. When the computer instructions stored in the memory 1612 are executed by the processor 1611 and the computer instructions stored in the memory 1622 are executed by the processor 1621, the network node 1600 can perform the operations performed by the node 100 or the node 200 in the embodiments shown in Figures 5A and 5B through 15.

[0233] It will be understood that the processor in the embodiments of the present application may be a central processing unit (CPU), and the processor may further be another general-purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or another programmable logic device, a transistor logic circuit, a hardware component, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor. It will be understood that the various numbers in the embodiments of the present application are merely used for distinction to facilitate the description, and are not used to limit the scope of the embodiments of the present application. [Explanation of symbols]

[0234] 100 nodes 110 Host 111 Pod 112 Pod 113 Common Application 114 Traffic Interception Module 120 Data Card 121 Communication Proxy 122 User Mode Protocol Stack 123 Control Plane Proxy 130 Network Interface Card 140 Data Channels 200 nodes 210 Host 211 Common Application 212 Common Application 213 Pod 214 Pod 215 Traffic Interception Module 220 Data Card 221 Communication Proxy 222 User Mode Protocol Stack 223 Control Plane Proxy 230 Network Interface Card 240 Data Channels 300 Network 400 Control Plane 500 nodes 1111 Microservices 1112 network port 1121 Microservices 1122 network port 1600 network nodes 1610 Host 1611 processor 1612 Memory 1620 Data Card 1621 processor 1622 Memory 2131 Microservices 2132 network port 2141 Microservices 2142 network port

Claims

1. A microservices-based service mesh system comprising: a first node, the first node including a first host and a first data card, the first data card being inserted into the first host, a first data channel being established between the first data card and the first host, computing resources of the first data card being independent of computing resources of the first host, a first pod running on the first host, a first microservice being provided to the first pod, the first data card accessing a network, and by using the network, receiving a service oriented architecture management policy sent by a management and control node, and performing service oriented architecture management on a first access request sent by the first host to the first data card via the first data channel based on the service oriented architecture management policy, the first access request being for the first microservice of a second microservice, the access request being obtained by the first host from the first pod, The service-oriented architecture management policy includes a correspondence between the second microservice and a network address of a second pod that executes the second microservice; The first data card is configured to determine, based on the service-oriented architecture management policy, the network address of the second pod that runs the second microservice, set a destination address of the first access request to the network address of the second pod, determine that the second pod is located on the first host, and send a modified first access request to the second pod via the first data channel.

2. A microservices-based service mesh system comprising: a first node, the first node including a first host and a first data card, the first data card being inserted into the first host, a first data channel being established between the first data card and the first host, computing resources of the first data card being independent of computing resources of the first host, a first pod running on the first host, a first microservice being provided to the first pod, the first data card accessing a network, receiving a service oriented architecture management policy sent by a management and control node by using the network, and performing service oriented architecture management on a first access request sent by the first host to the first data card via the first data channel based on the service oriented architecture management policy, the first access request being for the first microservice of a second microservice, the access request being obtained by the first host from the first pod, The service-oriented architecture management policy further includes a correspondence between a third microservice and a network address of a third pod that executes the third microservice; The first host is further configured to obtain a second access request of the first microservice for the third microservice from the first pod, and send the second access request to the first data card via the first data channel; The first data card is configured to determine, based on the service-oriented architecture management policy, the network address of the third pod that executes the third microservice, set a destination address of the second access request to the network address of the third pod, determine that the third pod is not located on the first host, and send the second access request by using the network.

3. the first node further comprises a first network interface card, the first network interface card being connected to the first data card, the first data card accessing the network by using the first network interface card; the first data card is configured to send the second access request to the first network interface card; The service mesh system of claim 2 , wherein the first network interface card is configured to transmit the second access request by using the network.

4. a second node, the second node comprising a second host, a second data card, and a second network interface card, the second data card being inserted into the second host, a second data channel being established between the second data card and the second host, a computing resource of the second data card being independent of a computing resource of the second host, the third pod running on the second host, the second network interface card being connected to the second data card, and the second network interface card accessing the network; The first data card is further configured to, when determining that the third pod is not located on the first host, set a service mesh identifier in the second access request; the second network interface card is configured to receive the second access request sent by the first network interface card, and if the second access request determines that the second access request carries the service mesh identifier, send the second access request to the second data card; 4. The service mesh system of claim 3, wherein the second data card is configured to, if the second data card determines that the third pod is located on the second host, send the second access request to the third pod over the second data channel.

5. a third node, said third node comprising a third host, said third host and said first host accessing said network, a first application running on said first host and a second application running on said third host; the first host is configured to obtain a third access request of the first application for a network address of the second application, and, when determining that the second application is not running on the first host, to transmit the third access request by using the network; 5. The service mesh system of claim 1, wherein 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. a first application and a second application running on the first host; 5. The service mesh system of claim 1, wherein the first host is configured to obtain a third access request of the first application for a network address of the second application, and to send the third access request to the second application if the first host determines that the second application is running on the first host.

7. a third node, the third node comprising a third host and a third data card, the third data card being inserted into the third host, a third data channel being established between the third data card and the third host, a computing resource of the third data card being independent of a computing resource of the third host, a fourth pod running on the third host, a fourth microservice being provided to the fourth pod, the third data card and the first host accessing the network; a first application running on the first host; The first host is configured to obtain a fourth access request of the first application to a network address of the third data card, and to transmit the fourth access request by using the network; 5. The service mesh system of claim 1, wherein the third data card is configured to receive the fourth access request sent by the first host and to send the fourth access request to the fourth microservice via the third data channel based on an identifier carried in the fourth access request that is for the fourth microservice.

8. A microservices-based service-oriented architecture management method applied to a microservices-based service mesh system, the service mesh system comprising a first node, the first node comprising a first host and a first data card, the first data card being inserted into the first host, a first data channel being established between the first data card and the first host, a computing resource of the first data card being independent from a computing resource of the first host, a first pod running on the first host, a first microservice being provided to the first pod, the first data card accessing a network, The method comprises: receiving, by the first data card by using the network, a service oriented architecture management policy sent by a management and control node; and performing, by the first data card based on the service-oriented architecture management policy, a service-oriented architecture management on a first access request sent by the first host to the first data card via the first data channel, the first access request being for the first microservice of a second microservice and being an access request obtained by the first host from the first pod, The service-oriented architecture management policy includes a correspondence between the second microservice and a network address of a second pod that executes the second microservice; performing, by the first data card, service-oriented architecture management on a first access request sent by the first host to the first data card via the first data channel based on the service-oriented architecture management policy; determining, by the first data card based on the service-oriented architecture management policy, the network address of the second pod that executes the second microservice, and setting a destination address of the first access request to the network address of the second pod; determining, by the first data card, that the second pod is located on the first host, and sending a modified first access request to the second pod via the first data channel.

9. A microservices-based service-oriented architecture management method applied to a microservices-based service mesh system, the service mesh system comprising a first node, the first node comprising a first host and a first data card, the first data card being inserted into the first host, a first data channel being established between the first data card and the first host, a computing resource of the first data card being independent from a computing resource of the first host, a first pod running on the first host, a first microservice being provided to the first pod, the first data card accessing a network, The method comprises: receiving, by the first data card by using the network, a service oriented architecture management policy sent by a management and control node; and performing, by the first data card based on the service-oriented architecture management policy, a service-oriented architecture management on a first access request sent by the first host to the first data card via the first data channel, the first access request being for the first microservice of a second microservice and being an access request obtained by the first host from the first pod, The service-oriented architecture management policy further includes a correspondence between a third microservice and a network address of a third pod that executes the third microservice; The method comprises: obtaining, by the first host, from the first pod, a second access request of the first microservice for the third microservice, and sending the second access request to the first data card via the first data channel; determining, by the first data card based on the service-oriented architecture management policy, the network address of the third pod that executes the third microservice, and setting a destination address of the second access request to the network address of the third pod; and determining, by the first data card, that the third pod is not located on the first host and sending the second access request by using the network.

10. the first node further comprises a first network interface card, the first network interface card being connected to the first data card, the first data card accessing the network by using the first network interface card; The step of determining, by the first data card, that the third pod is not located on the first host and transmitting the second access request by using the network includes: determining, by the first data card, that the third pod is not located on the first host and sending the second access request to the first network interface card; and transmitting, by the first network interface card, the second access request by using the network.

11. The service mesh system further comprises a second node, the second node comprising a second host, a second data card, and a second network interface card, the second data card being inserted into the second host, a second data channel being established between the second data card and the second host, a computing resource of the second data card being independent from a computing resource of the second host, the third pod running on the second host, the second network interface card being connected to the second data card, and the second network interface card accessing the network; The method comprises: if determining that the third pod is not located on the first host, setting, by the first data card, a service mesh identifier for the second access request; receiving, by the second network interface card, the second access request sent by the first network interface card, and if the second network interface card determines that the second access request carries the service mesh identifier, sending the second access request to the second data card; 11. The method of claim 10, further comprising: if determining that the third pod is located on the second host, sending, by the second data card, the second access request to the third pod via the second data channel.

12. The service mesh system further comprises a third node, the third node comprising a third host, the third host and the first host accessing the network, a first application running on the first host, and a second application running on the third host; The method comprises: obtaining, by the first host, a third access request of the first application for a network address of the second application, and transmitting the third access request by using the network when it is determined that the second application is not running on the first host; and receiving, by the third host, the third access request sent by the first host and sending the third access request to the second application.

13. a first application and a second application running on the first host; The method comprises:

12. The method of claim 8, further comprising: obtaining, by the first host, a third access request of the first application for a network address of the second application; and sending the third access request to the second application if the first host determines that the second application is running on the first host.

Images