CN114327850A

CN114327850A - Service grid system based on micro-service and service management method

Info

Publication number: CN114327850A
Application number: CN202011641555.6A
Authority: CN
Inventors: 张伟; 张永明; 张超盟
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2020-09-29
Filing date: 2020-12-31
Publication date: 2022-04-12

Abstract

The application relates to the technical field of data processing, in particular to a service grid system based on micro-services and a service management method. The system comprises a first node, wherein the first node comprises a first host and a first data card, the first data card is inserted into the first host, a first data channel is formed between the first data card and the first host, a first container group is operated on the first host, a first micro-service is arranged in the first container group, the first data card is accessed into a network, a service governance strategy sent by a control node is received through the network, and service governance is carried out on a first access request sent to the first data card by the first host through the first data channel according to the service governance strategy, wherein the first access request is an access request of the first micro-service acquired by the first host from the first container group to a second micro-service. The system performs service management on the access request from the host through the data card inserted in the host, saves the resources of the host and improves the efficiency of the service management.

Description

Service grid system based on micro-service and service management method

Technical Field

The present application relates to the field of data processing, and in particular, to a service grid system for micro services and a service management method.

Background

A service mesh (service mesh) technology is an application network technology based on a conventional Internet Protocol (IP) network. Based on the services grid technology, discovery and routing between services is no longer based directly on IP addresses, but rather on metadata information (including but not limited to service names, versions, etc.) of the services. The service grid technology strips non-functional service administration logic in distributed application of a micro service architecture (micro service architecture) from a service process into a sidecar (sidecar), provides connection, safety, flow control, gray level release and observation capabilities among services in a non-invasive mode, and achieves light service weight and infrastructure service administration.

As user demand grows, the size and calling complexity of microservices also grow rapidly. How to treat the micro-service in the continuous operation stage with high efficiency is an important problem of the service grid technology evolution.

Disclosure of Invention

The embodiment of the application provides a service grid system based on micro-services and a service management method, which can use a data card independent of a host to perform service management on an access request, and can improve the efficiency of service management while saving host resources.

In a first aspect, an embodiment of the present application provides a service grid system based on a microservice, including a first node, where the first node includes a first host and a first data card, the first data card is inserted into the first host, the first data card and the first host are provided with a first data channel, a first container group is operated on the first host, the first container group is provided with a first microservice, the first data card accesses to a network, receives, through the network, a service administration policy sent by a management and control node, and performs service administration on a first access request sent by the first host to the first data card via the first data channel according to the service administration policy, where the first access request is an access request of a first microservice obtained by the first host from the first container group to a second microservice.

That is, the nodes in the service grid system can utilize the peripheral devices of the host to perform service governance on the access request, so that the service governance aiming at the access request is prevented from occupying the resources of the host, and the efficiency of the service governance is improved.

In a possible implementation manner, the service administration policy includes a correspondence between the second micro service and a network address of a second container group running the second micro service, where the first data card is configured to determine, according to the service administration policy, the network address of the second container group running the second micro service, set a destination address of the first access request as the network address of the second container group, determine that the second container group is set in the first host, and send the modified first access request to the second container group through the first data channel.

That is, in this implementation, the data card may service governance calls between different microservices on the same node

In a possible implementation manner, the service governance policy further includes a correspondence between the third micro-service and a network address of a third container group running the third micro-service; the first host is also used for acquiring a second access request of the first micro service for the third micro service from the first container group and sending the second access request to the first data card through the first data channel; and the first data card is used for confirming the network address of a third container group for operating the third micro service according to the service governance strategy, setting the destination address of the second access request as the network address of the third container group, confirming that the third container group is not set in the first host, and sending the second access request through the network.

That is, in this implementation, the data card may service calls between microservices on different nodes.

In a possible implementation manner, the first node further includes a first network card, the first network card is connected with a first data card, and the first data card is accessed to the network through the first network card, where the first data card is used to send a second access request to the first network card; and the first network card is used for sending a second access request through the network.

That is to say, in this implementation manner, the data card may perform information interaction through the network card and the network, which are specially configured, thereby saving the overhead of data card resources caused by the information interaction between the data card and the outside.

In a possible implementation manner, the service grid system further includes a second node, where the second node includes a second host, a second data card, and a second network card, the second data card is inserted into the second host, the second data card and the second host are provided with a second data channel, the second host runs a third container group, the second network card is connected with the second data card, and the second network card is connected to the network, where the first data card is further configured to set a service grid identifier for the second access request when it is determined that the third container group is not set in the first host; the second network card is used for receiving a second access request sent by the first network card and sending the second access request to the second data card under the condition that the second access request carries the service grid identifier; and the second data card is used for sending a second access request to the third container group through the second data channel under the condition that the third container group is arranged in the second host.

That is to say, in this implementation, the first data card may add a service grid identifier to an access request for requesting access to a microservice, and thus, the peer device may quickly determine whether the access request is used for accessing the microservice according to whether the access request carries the service grid identifier.

In a possible implementation manner, the service grid system further includes a third node, where the third node includes a third host, the third host and the first host access a network, the first host runs a first application, and the third host runs a second application, where the first host is configured to obtain a third access request of the first application for a network address of the second application, and send the third access request through the network when it is determined that the second application is not running on the first host; and the third host is used for receiving the third access request sent by the first host and sending the third access request to the second application.

That is, in this implementation, the services grid system may implement calls between common applications on different nodes.

In a possible implementation manner, a first application and a second application run on a first host, where the first host is configured to obtain a third access request of the first application for a network address of the second application, and send the third access request to the second application when it is confirmed that the second application runs on the first host.

That is, in this implementation, the services grid system may implement calls between different common applications on the same node.

In a possible implementation manner, the service grid system further includes a third node, where the third node includes a third host and a third data card, the third data card is inserted into the third host, the third data card and the third host are provided with a third data channel, a fourth container group is run on the third host, a fourth micro-service is set in the fourth container group, the third data card and the first host access a network, where the first host runs a first application, and is configured to obtain a fourth access request of the first application for a network address of the third data card, and send the fourth access request through the network; and the third data card is used for receiving a fourth access request sent by the first host, and sending the fourth access request to the fourth micro service through the third data channel according to the identifier of the fourth micro service carried by the fourth access request.

That is, in this implementation, the service grid system may implement the invocation of the microservice by the common application using the data card.

In a possible implementation manner, the service grid system further includes a third node, where the third node includes a third host, a third application runs on the third host, and the third host accesses to a network, where 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 through the first data channel; the first data card is used for sending a fifth access request through a network; and the third host is used for receiving the fifth access request and sending the fifth access request to the third application.

That is, in this implementation, the service grid system may implement the invocation of the common application by the microservice using the data card.

In a second aspect, an embodiment of the present application provides a method for managing services based on microservices, where the method is applied to a service grid system based on microservices, where the service grid 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, the first data card and the first host are provided with a first data channel, a first container group runs on the first host, the first container group is provided with a first microservices, and the first data card is accessed to a network; the method comprises the following steps: the first data card receives a service management strategy sent by the control node through the network; and the first data card performs service governance on a first access request sent by the first host to the first data card through the first data channel according to the service governance strategy, wherein the first access request is an access request of a first micro service acquired by the first host from the first container group and aiming at a second micro service.

In one possible implementation, the service administration policy includes a correspondence between the second micro-service and a network address of a second container group that runs the second micro-service; the first data card performs service governance on a first access request sent by the first host to the first data card through the first data channel according to the service governance policy, and the service governance method comprises the following steps: the first data card confirms the network address of a second container group running a second micro service according to the service governance strategy, and sets the destination address of the first access request as the network address of the second container group; and the first data card confirms that the second container group is arranged in the first host, and sends the modified first access request to the second container group through the first data channel.

In a possible implementation manner, the service governance policy further includes a correspondence between the third micro-service and a network address of a third container group running the third micro-service; the method further comprises the following steps: the first host acquires a second access request of the first micro service for the third micro service from the first container group and sends the second access request to the first data card through the first data channel; the first data card confirms the network address of a third container group running a third micro service according to the service governance strategy, and sets the destination address of the second access request as the network address of the third container group; the first data card confirms that the third container group is not set in the first host, and sends a second access request through the network.

In a possible implementation manner, the first node further includes a first network card, the first network card is connected with a first data card, and the first data card is accessed to the network through the first network card; the first data card confirms that the third container group is not set in the first host, and sends a second access request through the network, including: the first data card confirms that the third container group is not arranged on the first host, and sends a second access request to the first network card; the first network card sends a second access request through the network.

In a possible implementation manner, the service grid system further includes a second node, where the second node includes a second host, a second data card, and a second network card, the second data card is inserted into the second host, the second data card and the second host are provided with a second data channel, the second host runs a third container group, the second network card is connected with the second data card, and the second network card is connected to the network; the method further comprises the following steps: the first data card sets a service grid identifier for the second access request under the condition that the third container group is not set in the first host; the second network card receives a second access request sent by the first network card, and sends the second access request to a second data card under the condition that the second access request carries a service grid identifier; and the second data card sends a second access request to the third container group through the second data channel under the condition that the third container group is arranged in the second host.

In a possible implementation manner, the service grid system further includes a third node, where the third node includes a third host, the third host and the first host access the network, the first host runs the first application, and the third host runs the second application; the method further comprises the following steps: the first host acquires a third access request of the first application for the network address of the second application, and sends the third access request through the network under the condition that the first host is confirmed not to run the second application; and the third host receives the third access request sent by the first host and sends the third access request to the second application.

In one possible implementation, a first application and a second application run on a first host; the method further comprises the following steps: the first host acquires a third access request of the first application for the network address of the second application, and sends the third access request to the second application under the condition that the first host is confirmed to run the second application.

In a possible implementation manner, the service grid system further includes a third node, where the third node includes a third host and a third data card, the third data card is inserted into the third host, the third data card and the third host are provided with a third data channel, the third host runs a fourth container group, the fourth container group is provided with a fourth micro-service, the third data card and the first host access a network, and the first host runs the first application; the method further comprises the following steps: the first host acquires a fourth access request of the first application for the network address of the third data card and sends the fourth access request through the network; and the third data card receives a fourth access request sent by the first host, and sends the fourth access request to a fourth micro service through a third data channel according to the identifier of the fourth micro service carried by the fourth access request.

In a possible implementation manner, the service grid system further includes a third node, where the third node includes a third host, a third application is run on the third host, and the third host is accessed to the network; the method further comprises the following steps: the first host acquires a fifth access request of the first micro-service for the network address of the third application, and sends the fifth access request to the first data card through the first data channel; the first data card sends a fifth access request through the network; the third host receives the fifth access request and sends the fifth access request to the third application.

It is understood that the service governance method provided by the second aspect is a method executed by a node in the service grid system provided by the first aspect, and therefore, reference may be made to the corresponding advantageous effects described above.

In a third aspect, an embodiment of the present application provides a network node, including a host and a data card, where the data card is inserted into the host; the host includes a first processor and a first memory for storing first computer instructions; the data card includes a second processor and a second memory for storing second computer instructions; when the network node is running, the first processor executes the first computer instructions and the second processor executes the second computer instructions, so that the network node executes the method provided by the second method.

In a fourth aspect, embodiments of the present application provide a computer storage medium including computer instructions, which, when executed on a network node, cause the network node to perform the method provided in the second aspect.

In a fifth aspect, the present application provides a computer program product, where the computer program product includes program code for implementing the method provided in the first aspect when the computer program product is executed by a processor in a network node.

The service grid system and the service management method provided by the embodiment of the application can use the data card with independent computing capacity to perform service management on the access request for calling the service, so that the service management does not occupy the computing resources of the host, the computing resources of the host are saved, and the service management efficiency is improved.

Drawings

FIG. 1 illustrates a service administration framework;

FIG. 2 illustrates a services grid system;

FIG. 3 illustrates a services grid system;

FIG. 4 illustrates a services grid system provided by an embodiment of the present application;

FIG. 5 illustrates a flow diagram of an application call based on the services grid system shown in FIG. 4;

fig. 6 shows a node initialization flowchart provided in an embodiment of the present application;

FIG. 7 is a flowchart illustrating an application invocation flow provided by an embodiment of the present application;

FIG. 8 is a flowchart illustrating an application invocation provided by an embodiment of the present application;

FIG. 9 is a flowchart illustrating an application invocation flow provided by an embodiment of the present application;

FIG. 10 is a flowchart illustrating an application invocation flow provided by an embodiment of the present application;

FIG. 11 is a flowchart illustrating an application invocation provided by an embodiment of the present application;

FIG. 12 is a flowchart illustrating an application invocation flow provided by an embodiment of the present application;

FIG. 13 is a flowchart illustrating an application invocation provided by an embodiment of the present application;

FIG. 14 is a flowchart illustrating an application invocation provided by an embodiment of the present application;

FIG. 15 is a flow chart of a service governance method provided by an embodiment of the present application;

fig. 16 shows a schematic block diagram of a network node according to an embodiment of the present application.

Detailed Description

The technical solution in the embodiments of the present invention will be described below with reference to the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of the present disclosure, and not all embodiments.

Reference throughout this specification to "one embodiment" or "some embodiments," or the like, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in one or more embodiments of the specification. Thus, appearances of the phrases "in one embodiment," "in some embodiments," "in other embodiments," or the like, in various places throughout this specification are not necessarily all referring to the same embodiment, but rather "one or more but not all embodiments" unless specifically stated otherwise.

Wherein in the description of the present specification, "/" indicates a meaning, for example, a/B may indicate a or B; "and/or" herein is merely an association describing an associated object, and means that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of the present specification, "a plurality" means two or more.

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

A microservice architecture is a Service Oriented Architecture (SOA) that partitions a complex system into multiple servlets or applications. The servlets or applications may be referred to as microservices. Each microservice is responsible for implementing an independent business logic. The microservice is built around business functions and can be deployed independently. The micro-services are mutually dependent, so that a series of functions can be provided. The microservice is easy to understand and modify, allowing language and framework selection flexibility.

In the micro-service architecture, service administration is also called SOA administration (service oriented architecture) and is a process for managing the adoption and implementation of the micro-service architecture.

Referring to fig. 1, a service governance framework based on Software Development Kit (SDK) is shown. Typical applications of this frame are springclosed, dubbo. In the framework, a client (client) or a server (server) is provided with a service governance function. Service administration functions are typically implemented with SDKs. In the development stage of the framework, the SDK carried by the framework is required to be used for client or server development. Generally, the framework is developed to support only a certain programming language, such as Java or the like. Although the framework has the characteristics of high performance and convenience in debugging. However, the framework which can not be incorporated by the client or the server of other existing programming languages is difficult to modify, and the modification with strong invasiveness is needed. Thereby causing unnecessary risks and development costs.

Fig. 2 illustrates a function that can implement automated deployment, automated scaling, maintenance, and the like of a container cluster. Wherein the container may be used to deploy or set up the microservice.

The system shown in fig. 2 employs Pod-level sidecars (sidecars) as proxies for applications or microservices, which may provide service administration functions transparent to the user, such as link encryption, fusing, current limiting, gray scale distribution, link tracking, etc. Unlike traditional network proxies, the Istio does not simply load balance the target I P address at the kernel or hardware level, but rather the sidecar is responsible for target service discovery and load balancing. The calling end only needs to access the virtual address or the logic address of the service. The sidecar decides how to convert the service meta-information into a network address that can be actually accessed and sends the traffic to the invoked microservice according to the network address.

Fig. 3 shows that the system can deploy Pod-level sidecars and also node-level sidecars.

Whether the system shown in fig. 2 or the system shown in fig. 3, the sidecar takes up excessive host resources (e.g., CPU, memory, etc.) while bringing transparent service management capability. Especially for public cloud environments, a large number of Pod needs to be deployed, thereby bringing about non-negligible overhead of host resources. When the service is busy, the sidecar and the micro service may seize resources mutually. If the load of the CPU is too high, the input/output (I/O) can not be processed in time, and then the sidecar can be congested, and the time delay of the whole link can be worsened.

The embodiment of the application provides a service grid system based on micro-services. Referring to fig. 4, the service grid system may include a node 100. Node 100 may include a host 110, a data card 120, and a network card 130.

The host 110 may be a physical machine, such as a server. The host 110 may be running with one or more banks of containers. Each container group may consist of one or more containers (containers). Illustratively, a container group may refer to Pod in K8 s. The host 110 may be deployed with one or more microservices. Each microservice may be arranged or run in a container group. Micro-services, which may also be referred to as micro-service applications, may implement an independent business logic. The micro-services can provide corresponding service functions through the calling and called relations.

Data card 120 is a hardware device with independent computing resources, for example, data card 120 has a dedicated processor and memory. Illustratively, the data card 120 may be a Software Defined Infrastructure (SDI). Data card 120 may also be referred to as an SDI data card. Data card 120 may be inserted into host 110 as a peripheral device to host 110. Data card 120 may service access requests from host 110. For example, a sidecar corresponding to the microservice on host 110 may be deployed on data card 120 such that data card 120 may function as a sidecar. Because the computing resources of the data card 120 are independent of the computing resources of the host 110, the data card 120 plays the role of a sidecar, thereby avoiding preemption of the computing resources of the host 110 when the sidecar performs service management. In addition, the operation of the sidecar can use the computing resources of the data card 120 nearby, thereby improving the efficiency of service management and reducing network delay.

As shown in fig. 4, a data channel 140 is provided between host 110 and data card 120. Host 110 may send an access request for service administration to data card 120 via data channel 140, so that data card 120 may administer the access request with service administration, such as encryption, load balancing, etc. Illustratively, the data channel 140 may be a peripheral component interconnect express (PCIe) bus, or the data channel 140 is carried by a PCIe bus. In one example, the data channel 140 may receive an access request sent by the host 110 based on remote direct data access (RDMA) technology. Specifically, host 110 may transfer access request notification data channel 140 directly to the storage area of data card 120. Therefore, the data between the host and the data card can be quickly transmitted, and the network delay is further reduced.

The network card 130 accesses the network 300 to send data to the network 300 and to retrieve data from the network 300. The network card 130 may be in communication connection with the host 110 and the data card 120, respectively, so that the network card 130 may transmit data acquired from the host 110 or the data card 120 to the network 300 and transmit data acquired from the network 300 to the host 110 or the data card 120. Illustratively, the network card 130 may be a peripheral device that is plugged into the host 110. In one example, the network card 130 is embodied as an SDI. Network card 130 may also be referred to as an SDI network card.

In some embodiments, network card 130 and data card 120 may be two separate hardware cards or devices. In some embodiments, network card 130 and data card 120 may be provided on a single hardware card or hardware device.

In some embodiments, with continued reference to FIG. 4, the services grid system may also include a node 200. The host 210, the data card 220, the network card 230, and the data channel 240 included in the node 200 may be implemented by referring to the host 110, the data card 120, the network card 130, and the data channel 140, respectively, which are not described herein again.

The service grid system may further include more nodes, and each node may be implemented with reference to the node 100, which is not described in detail herein.

The foregoing exemplarily illustrates the structure of the service grid system provided in the embodiment of the present application. Next, in various embodiments, examples describe the functionality of modules or components in the services grid system.

Figure 5 shows a flow diagram of an application call based on the services grid system shown in figure 4.

As shown in fig. 5, the host 110 may be provided with one or more container groups. Specifically, the operating system of host 110 (e.g.,

) Can be divided into user space and system kernel. The one or more container groups may operate in user space. The one or more container groups may include container group 111, container group 112. The container group 111 is provided with a micro service 1111 and a network port 1112. Microservice 1111 may generate access requests to invoke services provided by other microservices or applications. The services provided by microservice 1111 may also be invoked by other microservices or applications. Here, the micro service 1111 may transmit data to the outside or receive data from the outside through the network port 1112. The group of containers 112 includes a microservice 1121 and a portal 1122. Microservice 1121 may generate access requests to invoke services provided by other microservices or applications. Services provided by microservice 1121 may also be invoked by other microservices or applications. Here, the microservice 1121 may transmit data to the outside or receive data from the outside through the network port 1122.

The host 110 may also be provided with a general application 113. The common application may refer to an application other than the microservice, for example, an application based on secure shell protocol (SSH) or an application based on a remote terminal protocol (telnet). The generic application 113 may invoke services provided by microservices or other generic applications. The services provided by the generic application 113 may also be invoked by microservices or other generic applications. In the embodiment of the present application, a general application may also be referred to as a general service.

The host 110 may also be provided with a traffic interception module 114. Traffic intercept module 114 may screen out access requests for service administration and send the access requests for service administration to data card 120 via data channel 140. The traffic intercepting module 114 may be disposed in a system core.

In particular, the access request generated by the microservice on the host 110 may include a service identification. The access request is used for requesting to establish network connection with a target application thereof so that the target application provides services for the micro-service generating the access request. The target application can be other micro-services or common applications. In general, a service identification may be a logical address or descriptive information that is not a network address of a particular microservice or application, or that is not a network address of a group of containers running the microservice or application. The service identification may be used to describe or identify a service. In other words, the service identifier is used to describe or indicate the service requested by the access request in which it is located. In one example, the service identification may include a service name and/or a service version number, among others. In one example, the service identification may be preset information that declares or indicates that the access request needs service administration. The traffic interception module 114 may have a need to administer list consisting of multiple service identifications. For example, the traffic interception module 114 may obtain the list of treatments required from the control plane proxy. Wherein, the list to be managed in the control plane agent can be obtained from the control plane. In one example, the need to administer list may be generated by the control plane proxy. In another example, a developer or operation and maintenance personnel servicing the grid system may configure the need to administer list at the control plane.

In addition, it can be understood that for an access request requiring service administration, the target application of the access request is not actually determined before the service administration is performed. One operation of service administration is to determine a target application for an access request based on a service identification in the access request.

The traffic intercept module 114 obtains access requests from the user space of the host 110. And judging whether the service identifier in the access request is located in a list to be administered. If the service identifier in the access request is located in the list to be administered, it may be determined that the access request is an access request that needs to be subjected to service administration, and the access request is sent to the data card 120. If the service identifier in the access request is not located in the administration list, it may be determined that the access request does not need to be subjected to service administration, and the access request may be directly sent to the network 300 through the network card 130 so as to be sent to a corresponding node through the network 300. For example, the service identifier in a certain access request may be a network address of a certain general application, which is not located in the need to administer list. Network card 130 may send the service request to the corresponding application directly according to the network address.

With continued reference to fig. 5, the data card 120 may include a communication agent 121, a user mode protocol stack 122, and a control plane agent 123. The communication agent 121 may administer services to the access request, such as encryption/decryption, determining a microservice or application that provides the service requested by the access request, and so forth. For example, the communication agent 121 may be or have the functionality of a sidecar. More specifically, in one example, the communication agent 121 may be a sidecar in the K8s system or function as a sidecar in the K8s system.

The user mode protocol stack 122 may be used to forward access requests to the communication agent 121 and to forward access requests issued by the communication agent 121 to other modules or components. The specific functions of the user mode protocol 122 will be described in the following specific embodiments, and will not be described herein.

The node 200 includes a host 210, a data card 220, a network card 230, and a data channel 240. The user space side of the host 210 is provided with a normal application 211, a normal application 212, a container group 213, and a container group 214. Wherein the container set 213 is provided with a special micro service 2131 and a net port 2132. The group of containers 214 is provided with a special microservice 2141 and a portal 2142. The system kernel side of the host 210 is provided with a traffic interception module 215. The data card 220 may be provided with a communication agent 221, a user mode protocol stack 222, a control plane agent 223, and the like. The functions of the components or modules in the node 200 may refer to the above description of the corresponding components or modules in the node 100, and are not described herein again.

After the service grid system is started, the nodes therein may be initialized. Referring to fig. 6, taking node 100 as an example, initialization may include the following steps.

The control plane proxy 123 may perform step 601 by sending an indication to the user mode protocol stack 122 that control plane proxy ingress and egress traffic is not to be intercepted. The ingress and egress traffic of the control plane proxy 123 refers to data with the sending end being the control plane proxy 123 and data with the receiving end being the control plane proxy 123. The indication includes a User Identity (UID) of the control plane proxy. The user mode protocol stack 122 may not intercept traffic (or data) sent by the control plane proxy or traffic directed to the control plane based on the user identity of the control plane proxy. That is, the user mode protocol stack 122 may recognize the ingress and egress traffic of the control plane agent according to the user identifier of the control plane agent, so that the ingress and egress traffic of the control plane agent 123 may not be intercepted, so that the ingress and egress traffic of the control plane agent 123 may freely pass through the user mode protocol stack 122.

The control plane proxy 123 may perform step 602, receiving the service list, the service administration policy, and the special micro-service list sent by the control plane 400.

The control plane 400 is a control plane in the serving grid. The control plane 400 may be referred to as a governing node. Alternatively, the control plane 400 may be a program or a module running on a management node and having control and management functions.

The service list may include a service identification and a network address correspondence list of micro-services or applications that may provide the service corresponding to the service identification. The micro service may register a name, a service identifier, a network address of a group of containers running the micro service, and the like of the micro service in the control plane 400. Illustratively, the network address of the group of containers may include an IP address and a port number of the group of containers. Thus, the control plane 400 may obtain the service list according to the correspondence between the service identifier of the micro service and the network address of the container group running the micro service.

In some embodiments, the service list may also be referred to as, or include, a service list.

In some embodiments, the service administration policy may include a policy of whether to encrypt or decrypt certain access requests, whether to load balance certain access requests, and the like. In addition, the specific implementation of the service governance policy may also be introduced with reference to the prior art, and will not be described herein again.

The special microservice list includes identification information for one or more special microservices. It will be appreciated that, in general, in a services grid system, an access request for requesting a connection to a microservice needs to go through two service governments, one for a communication agent on the sending side (e.g., node 100) and the other for a communication agent on the receiving side (e.g., node 100). The special micro-service is more special, and particularly, the access request for requesting connection with the special micro-service only needs to be treated once.

Continuing with fig. 6, the control plane proxy 123 may perform step 603a to send the list of treatments required to the traffic intercept module 114. In some embodiments, the need to administer list may be configured by a developer or an operation and maintenance person of the service grid system. In some embodiments, the control plane proxy 123 may automatically generate the list to be administered from the service list. As described above, the service list may include a service identifier and a network address correspondence list of micro-services or applications that may provide the service corresponding to the service identifier. The control plane proxy 123 may use the service identification in the service list as the required governance list. It should be noted that although two ways of configuring the need to administer lists are described above. When the scheme provided by the embodiment of the application is specifically implemented, a mode of automatically generating the list to be managed according to the service list is adopted, so that the dependence on manpower is further reduced.

The control plane proxy 123 may perform step 603b to send the special micro-service list to the user mode protocol stack 122. When receiving an access request, the user mode protocol stack 122 may determine whether the micro-service requested to connect is located in the special micro-service list. If the micro-service requested for connection is located in the special micro-service list, the user mode protocol stack 122 does not send the access request to the communication agent 121, but directly sends the access request to the host 110.

The control plane proxy 123 may also perform step 603c, sending the service list, the service governance policy, to the communication proxy 121, so that the communication proxy 121 may service the access request according to the service list and the service governance policy. Specifically, the service identifier in the access request may be used to determine the connection target application of the access request according to the service list, that is, to determine the network address of the target application of the access request. For example, if the service administration policy includes an encryption policy, the communication agent 121 may encrypt the access request.

The control plane proxy 123 may also perform step 604 to receive the updated service list, the updated service governance policies, and the updated special micro-service list from the control plane 400.

The control plane proxy 123 may further execute step 605a to send the updated list to be managed to the traffic intercepting module 114. In some embodiments, the updated abatement list may be generated by the control plane proxy 123 from the updated service list.

Control plane proxy 123 may also perform step 605b, sending the updated special micro-service list to user mode protocol stack 123.

The control plane proxy 123 may also perform step 605d, sending the updated service list, the updated service governance policies, to the communication proxy 121.

The initialization of the node 100 can be realized through the above steps, and the initialization of other nodes can be realized by referring to the initialization of the node 100, which is not described herein again.

After the above initialization of the nodes in the services grid system, the following calls may be implemented.

(one), the microservice on node 100 invokes other microservices on node 100.

(II) the microservice on node 100 invokes the microservice on node 200.

And (III) the common application of the node 100 calls the common application on the node 200.

And (IV) the micro-service of the node 100 calls the special micro-service of the node 200. The specific micro service will be specifically described below, and will not be described herein again.

And (V) the common application on the node 200 calls other common applications on the node 200.

Sixth, the node 200 forwards the access request of the node 100.

(seventh), a generic application on node 100 invokes a microservice on node 200.

(eight), the microservice on node 100 invokes the normal application of node 200.

Next, in different embodiments, the eight calling cases are specifically described.

In one embodiment, the microservice on node 100 invokes other microservices on node 100.

In the present embodiment, the example of micro service 1111 invoking micro service 1121 is described. Micro service 1111 may generate an access request for connecting micro service 1121 to establish a communication connection between micro service 1111 and micro service 1121, so that micro service 1121 may provide related services for micro service 1111, thereby enabling micro service 1111 to invoke micro service 1121. It is understood that in the micro-service architecture, micro-service 1111 does not actually know what services it needs to connect to micro-service 1121 when generating the access request, but only knows what services it needs, and then carries the service identifier of such service in the access request, or as the original destination address of the access request. After the access request is subjected to service administration by the communication proxy, the target application actually providing service for the micro service 1111 may be determined, and the access request may be forwarded to the target application to establish a connection between the micro service 1111 and the target application.

Next, a specific data transfer path for invoking microservice 1121 by microservice 1111 will be described with reference to fig. 7 and 5.

Microservice 1111 may generate access request a 1. The access request a1 may include a service identification of the service that micro-service 1121 may provide. Illustratively, access request a1 may be a network socket (socket) connection request, where the service identification in access request a1 may be referred to as the original socket Destination (DST) of access request a 1. Microservice 1111 may perform step 701, sending access request a1 to traffic intercept module 114. The traffic intercepting module 114 may determine whether the access request a1 needs to perform service administration by using the list to be administered according to the service identifier in the access request a 1. The service identifier in the access request a1 is a service identifier corresponding to the micro service 1121, and the service identifier is located in a list to be managed, and it is determined that the access request a1 needs to perform service management. Thus, the traffic intercept module 114 may perform step 702, forwarding the access request a1 to the data path 140.

In one illustrative example, the data flow of steps 701, 702 may be as shown in (1) of fig. 5. Access request a1 that microservice 1111 may generate may be a network socket (socket) connection request. Wherein the service identification in access request a1 may be used as the original socket destination address for the socket connection. Access request a1 may be sent to traffic intercept module 114. The traffic intercepting module 114 analyzes the service corresponding to the service identifier as a service in the service grid, that is, the service corresponding to the service identifier needs to be subjected to service administration. The traffic intercept module 114 forwards the access request a1 to the data path 140.

The data channel 140 may perform step 703 of sending the access request a1 to the user mode protocol stack 122. Step 703 can refer to (2) in fig. 5. Illustratively, as described above, the data channel 140 is or is carried by a PCIe bus. In step 703, the side of the data channel 140 located at the host 110 may convert the access request a1 into a data stream under the PCIe protocol, and the channel data channel 140 transmits the converted data stream. Data channel 140 at one end of data card 120 may convert access request a1 presented in a data stream under the PCIe protocol into a form of a socket connection request and send access request a1 to user mode protocol stack 122. In addition, in the embodiment of the present application, the user mode protocol stack 122 is independent of a network protocol stack carried by an operating system of the host 110, so that system overhead caused by data interaction between the host 110 and the data card 120 can be avoided or reduced.

The user mode protocol stack 122 may perform step 704 to send an access request a1 to the communication agent 121. Step 704 can refer to (2) in fig. 5. Illustratively, network state protocol stack 122 may maintain the service identification in access request A1, i.e., the original socket destination address of access request A1. The network state protocol stack 122 may update the socket target address of the access request a1 to the network address of snoop port 1 of the communication agent 121, so that the access request a1 may be sent to snoop port 1. To this end, a socket connection or socket link between microservice 1111 and listening port 1 may be established, where listening port 1 may also be referred to as an outgoing traffic (outbend) listening port of communication agent 121.

The communication agent 121 may obtain the access request a1 through the listening port 1 and obtain the service identification in the access request a 1. It will be appreciated that network state protocol stack 122 is located on the socket link between microservice 1111 and snoop port 1, and maintains the service identification in access request a 1. The communication agent 121 may retrieve the service identification in the access request a1 from the user mode protocol stack 122 via the socket link.

The communication agent 121 may perform step 705 to service the access request a 1. Specifically, the communication agent 121 may perform service governance according to the service identification in the access request a1, according to the service governance policy. Wherein, the service governance may include selecting, through load balancing, an application that provides the service described by the service identifier for the micro service 1111. In this embodiment, the selected application providing the service described by the service identifier for micro service 1111 may be determined as micro service 1121, that is, micro service 1121 is determined as the target application of access request a 1. Illustratively, upon determining the target application of access request A1, the socket target address of access request A1 may be updated to the network address of microservice 1121. The network address of the micro service 1121 may specifically refer to a network address of a container group running the micro service 1121, that is, a network address of the container group 112. Illustratively, the network address of the set of containers 112 may include an IP address and a port number of the set of containers 112.

The communication agent 121 may perform step 706 to send the access request a1 to the user mode protocol stack 122. The user mode protocol stack 122 may perform step 707 to determine that the target application of the access request a1 is located at the local node. The user mode protocol stack 122 may then perform step 708, sending the access request a1 to the listening port 2 of the communication agent 121. Specifically, referring to (3) and (6) in fig. 5, the user mode protocol stack 122 may determine that the User Identity (UID) of the sending process of the access request a1 is the executor of step 706 by the communication agent 121, and determine that the target application (i.e., the micro service 1121) of the access request a1 is located in the node (i.e., the node 100) according to the socket target address in the access request a 1. Then, the user mode protocol stack 122 may determine that it receives the inbound (inbound) traffic of the access request a1 in step 706, so as to forward the access request a1 to the listening port 2 of the communication proxy 121, thereby ensuring that even if the micro service calls other local micro services, the micro service can enter the communication proxy twice symmetrically, and perform twice service administration. Here, the listening port 2 may be referred to as an inbound traffic (inbound) listening port of the communication agent 121.

The communication agent 121 may perform step 709 to service the re-received access request a 1. For example, in the service administration of step 705, the service data or user data in access request a1 is encrypted. The encrypted data may be decrypted in the service mediation of step 709.

The communication agent 121 may perform step 710 to send the re-served access request a1 to the user mode protocol stack 122. Before performing step 710, the communication agent 121 may call an Application Programming Interface (API) provided by the user mode protocol stack 122 to add a service administration identifier to the access request a 1. The service administration flag is used to indicate that access request a1 has been subjected to two service administrations and that the target application is located locally.

The user mode protocol stack 122 may perform step 711 to send an access request a1 to the data lane 140. Referring to fig. 5 (7) and (8), when receiving the access request a1 sent in step 710, the user mode protocol stack 122 may determine that the access request a1 is ingress traffic and the target application is located in the container group of the local node according to the service governance identifier carried by the access request a 1. Thus, step 711 may be performed to send an access request A1 to the data channel 140.

The data path 140 may perform step 712 to send an access request a1 to the traffic intercept module 114. Referring to (8) in fig. 5, the data channel 140 at the end of the data card 120, upon receiving the access request a1 sent in step 711, may convert the access request a1 into a data stream under the PCIe protocol, and transmit the data stream under the PCIe protocol to the host 110. When the PCIe data stream arrives at the end of the host 110 where the data channel 140 is located, the PCIe data stream may be converted into a socket connection request.

The traffic interception module 114 is specifically a traffic interception module, that is, it only intercepts or filters traffic sent by the host 110 to the outside, but does not filter traffic received by the host 110 from the outside. When receiving the access request a1 sent in step 712, the traffic interception module 114 may send the access request a1 to a target application (i.e., the microservice 1121) according to a socket target address (i.e., a network address of the microservice 1121) of the access request a1, thereby establishing a socket connection between the microservice 1111 and the microservice 1121, and implementing the call of the microservice 1111 to the microservice 1121.

In a second embodiment, a microservice on node 100 invokes a microservice on node 200.

In the present embodiment, the description will be made by taking microservice 1111 as an example to call microservice 2141. Therein, micro service 1111 may generate an access request for connecting micro service 2141 to establish a communication connection between micro service 1111 and micro service 2141, so that micro service 2141 may provide related services for micro service 1111, thereby implementing micro service 1111 to invoke micro service 2141. It will be appreciated that in the micro-service architecture, micro-service 1111 does not actually know what services it needs to connect to micro-service 2141 when generating the access request, but only knows what services it needs, and thus carries such services in the access request, or as the original destination address of the access request. After the access request is subjected to service administration by the communication proxy, the target application actually providing service for the micro service 1111 may be determined, and the access request may be forwarded to the target application to establish a connection between the micro service 1111 and the target application.

Next, a specific data transfer path for invoking the microservice 2141 by the microservice 1111 will be described with reference to fig. 8 and 5.

Microservice 1111 may generate access request a 2. The access request a2 may include a service identification of the service that the microservice 2141 may provide. Microservice 1111 may perform step 801 of sending access request a2 to traffic intercept module 114. The traffic intercepting module 114 may determine whether the access request a2 needs to perform service administration by using the list to be administered according to the service identifier in the access request a 2. The service identifier in the access request a2 is a service identifier corresponding to the micro service 2141, and the service identifier is located in the list to be administered, and it is determined that the access request a2 needs to be administered with service administration. Thus, the traffic intercept module 114 may perform step 802 to forward the access request a2 to the data path 140.

The data path 140 may perform step 803 to send the access request a2 to the user mode protocol stack 122.

The user mode protocol stack 122 may perform step 804 to send an access request a2 to the communication agent 121.

Specifically, reference may be made to the above description of step 701, step 702, step 703 and step 704 for performing step 801, step 802, step 803 and step 804, which are not described herein again.

The communication agent 121 may perform step 805 to service the access request a 2. Specifically, the communication agent 121 may perform service governance according to the service identification in the access request a2, according to the service governance policy. Wherein, the service governance may include selecting, through load balancing, an application that provides the service described by the service identifier for the micro service 1111. In this embodiment, the selected application providing the service described by the service identifier for micro service 1111 may be determined as micro service 2141, that is, micro service 2141 is determined as the target application of access request a 2. Illustratively, upon determining that microservice 2141 is the target application of access request a2, the socket target address of access request a2 may be updated to the network address of microservice 2141. The particular microservice 2131 may be referred to as the target application of access request a4 and the network address of the particular microservice 2131 may be referred to as the target application address of access request a 4. The network address of the micro service 2141 may specifically refer to a network address of a container group running the micro service 2141, that is, a network address of the container group 214. Illustratively, the network address of the container group 214 may include an IP address and a port number of the container group 214.

The communication agent 121 may perform step 806 to send the access request a2 to the user mode protocol stack 122. The user mode protocol stack 122 may perform step 807 by determining that the actual target application of access request a2 is not located at the node. The user mode protocol stack 122 may then perform step 808 to add the service grid identification for access request a 2. The service grid identifies that the target application for which access request a2 belongs to a microservice. The specific form of the service grid identifier can be a custom field, a number and the like. In a particular form, a developer or operation and maintenance personnel of the service grid system may customize the service grid identification. The user mode protocol stack 122 may also perform step 809 of encapsulating the target application address of the access request a 2. As described above, the target application address determined in step 805 is the network address of the micro service 2141. It is understood that micro service 2141 resides on a certain node (i.e., node 200). In step 809, the network address of the micro-service 2141 may be encapsulated as the IP address of the node. For example, the network address of the microservice 2141 may be the network address of the container set 214. The network address of the container group 214 may include an IP address and a port number of the container group 214. Container 214 is located on node 200, then in step 809 the network address of micro-service 2141 is encapsulated as the IP address of node 200.

In addition, the execution of step 806, step 807, step 808, and step 809 can also refer to (3) in fig. 5. Specifically, in step 806, the access request a2 is sent to the user mode protocol stack 122 as outbound traffic issued by the communication agent 121. The user mode protocol stack 122 may determine that the communication agent 121 is the sender of the outgoing flow according to the data stream sending process UID of the access request a2, and determine that the target application is not located at the local node (node 100) according to the target application address of the access request a 2. The access request a2 may then be subject to service grid identification additions, destination application address encapsulation, and the like.

Next, the user mode protocol stack 122 may perform step 810 to send an access request a2 to the network card 130. Referring to (4) in fig. 5, when processing traffic to the outside, the network card may be directly transmitted to the network card of the target node through the network. Referring back to fig. 8, in step 811, the network card 130 may send an access request a2 to the network card 230. Specifically, the network card 130 may send the access request a2 to the network card 230 over the network 300.

Referring to fig. 8, the network card 230 may perform step 812 to recover the target application address from the access request a 2; and step 813 is performed to determine that access request a2 has a service grid identification. Referring to fig. 5 (10), after receiving the data packet carrying the access request a2, the physical network card of the network card 230 may recover the destination application address of the access request a2 and determine whether the access request a2 has the service grid identifier.

The network card 230 may then perform step 814, sending the access request a2 to the user mode protocol stack 222. Referring also to (12) of fig. 5, the network card 230 forwards the access request a2 to the user mode protocol stack 222 through a virtual network port between the network card and the data card 220.

The user mode protocol stack 222 may perform step 815 to determine that the target application of the access request a2 is not a special microservice. As described above, during initialization, the user mode protocol stack may obtain a list of special microservices. The special microservice list includes identification information for 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 micro-service according to the network address of the target application, i.e., determine that the network address of the target application is not located in the special micro-service 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, sending the access request A2 to the communication proxy 221. The communication agent 221 may perform secondary service administration on the access request a 2. For example, the service data in access request a2 is decrypted. Thereafter, the communication proxy 221 may execute step 818 to send the access request a2 subjected to the secondary service treatment to the user mode protocol stack 222. Wherein the communication proxy 221 may call an API provided by the user mode protocol stack 222 to add a service administration identity to the access request a2 before performing step 818. The service administration flag is used to indicate that access request a2 has been subjected to service administration and that the target application is located locally (the node where the communication proxy 221 is located).

Execution of steps 815-818 referring also to (14) in fig. 5, the user mode protocol stack 222 determines that the target application address of the access request a2 is not an address of a non-special micro service, i.e. the target application is not a special micro service, and forwards the access request a2 to the listening port 3 of the communication agent 221. The listening port 3 is an incoming traffic listening port of the communication agent 221. The communication agent 221 records the access request a2 as incoming traffic and administers the service to the access request a 2. When service administration is performed on access request a2 and access request a2 is sent to an upstream module or component, the API of the user mode protocol stack 222 may be called to add a service administration identification to access request a 2.

The user mode protocol stack 222 may perform step 819 to send an access request A2 to the data channel 240. Referring to fig. 5 (15), when receiving the access request a2 sent in step 818, the user mode protocol stack 222 may determine that the access request a2 is inbound direction traffic and the target application is located in the container group of the local node according to the service administration identifier carried in the access request a 2. Thus, step 819 may be executed to send the access request A2 to the data channel 240.

The data channel 240 may perform step 820 to send the access request a2 to the traffic intercept module 215. Referring to (15) in fig. 5, the data channel 240 located at one end of the data card 120, upon receiving the access request a2 sent in step 819, may convert the access request a2 into a data stream under the PCIe protocol, and transmit the data stream under the PCIe protocol to the host 210. When the PCIe data stream arrives at the end of the host 210 where the data channel 240 is located, the PCIe data stream may be converted into a socket connection request.

The traffic interception module 215 is specifically a traffic interception module, that is, it only intercepts or filters traffic sent by the host 210 to the outside, but does not filter traffic received by the host 210 from the outside. The traffic interception module 215, upon receiving the access request a2 sent through step 820, may perform step 821, sending an access request a2 to the microservice application 2141. Specifically, the address of the socket target of the access request a2 (i.e., the network address of the microservice 2141) may be used to send the access request a2 to the target application (i.e., the microservice 2141).

Thus, a connection between microservice 1111 and microservice 2141 can be established, and invocation of microservice 1111 on microservice 2141 can be achieved. Illustratively, the access request a2 may specifically be a socket connection request, and the established connection between the microservice 1111 and the microservice 2141 may be a socket connection.

In the third embodiment, the normal application of the node 100 calls the normal application on the node 200.

Next, with reference to fig. 9 and fig. 5, the scheme provided in this embodiment will be described by taking the general application 113 as an example to call the general application 211.

The general application 113 may generate the access request A3, the target application address of the access request A3 being the network address of the general application 211. Illustratively, the network address of the general application 211 may include an IP address and a port number of the general application 211. Referring to fig. 9, the general application 113 may perform step 901 to send an access request a3 to the traffic intercepting module 114. The traffic intercepting module 114 may determine that the network address of the general application is not located in the list to be administered, and then may perform step 902 to send an access request A3 to the virtual port of the host 110, so that the virtual port of the host 110 may perform step 903 to send an access request A3 to the network card 130. Referring also to (9) in fig. 5, the general application 113 may send an access request a 3. The traffic intercepting module 114 determines that the target application of the access request a3 is a normal application, and directly sends the access request to the network card 130 through the virtual network port.

Network card 130 may perform step 904 of encapsulating the target application address of access request a 3. Specifically, as shown in (5) in fig. 5, the network card 130 may encapsulate the target application address when detecting that the target application of the access request a3 is located at a node other than the node 100. The target application address may be encapsulated as the address of the node where the target application is located. For example, the destination application address is a network address of the general application 211, which is located on the node 200, and the network address may be encapsulated as an IP address of the node 200. Illustratively, the network address of the general application 211 may include an IP address and a port number of the general application 211.

Network card 130 may also perform step 905 by sending an access request a3 to network card 230. Specifically, referring to (5) in fig. 5, the network card 130 may send the access request A3 to the network 300 through a physical network card, and then the network 300 may forward the access request A3 to the network card 230 according to the destination address of the access request A3 (i.e., the address obtained by encapsulating in step 904).

Upon receiving the access request A3, the network card 230 may perform step 906 to recover 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.

Network card 230 may perform step 907 to determine that access request a3 does not have a service grid identification. It will be appreciated that service request a3 does not pass through data card 120 and, therefore, does not have a service grid identification. Network card 230 may also perform step 908 to determine that the target application address is not the serving mesh gateway address. The service mesh gateway address refers to the address of a certain listening port of the communication agent. For example, listening port 3 in fig. 5 may serve as the serving mesh gateway address for node 200. Thereafter, the network card 230 may perform step 909 to send an access request a3 to the virtual portal of the host 210. The virtual portal of the host 210 may perform step 910 to send an access request a3 to the traffic interception module 215. The traffic interception module 215 may perform step 911 to send an access request a3 to the generic application 211.

Execution of steps 907-911 referring also to (11) in fig. 5, the network card 230 may determine that the access request A3 does not have a serving grid identification and the target application address is not a serving grid gateway, and may forward the access request A3 to the host 210 through the virtual portal. The system kernel of the host 210 may then send the access request a3 directly to the normal application 211.

Therefore, the connection between the common application 113 and the common application 211 can be established, and the call of the common application 113 to the common application 211 is realized. Illustratively, the access request a3 may specifically be a socket connection request, and the established connection between the general application 113 and the general application 211 may be a socket connection.

In the fourth embodiment, the micro-service of the node 100 invokes a special micro-service of the node 200.

Special microservices generally include, but are not limited to, applications that may connect without going through a second communication agent (e.g., a sidecar). That is to say, the access request of the target application as the special micro service can reach the target application without secondary service management, and the connection between the source application and the target application is realized. The source application refers to an application that generates an access request. Typical special microservices are microservices providing a flow limiting service, microservices providing a data collection service, etc.

One scenario for invoking special microservices is that an access request initiated by a microservice in a host user space passes through a first communication proxy, and the communication proxy needs to actively invoke the special microservice to perform service management on the access request. For example, a microservice providing a current limit service may be invoked and a determination may be made as to whether the access request exceeds a current limit threshold. If the current limit threshold is exceeded, the communication agent may return a failure response to the microservice that initiated the access request. The communication agent may also invoke the data collection service as the access request passes through the first communication agent, so as to report the statistical link invocation data to the data collection service for network invocation topology mapping.

Since the special micro-service belongs to the micro-service in the service grid, it is difficult to configure an interception scheme for intercepting the access request of the target application as the special micro-service in the network card, so that the access request which has been subjected to the first service administration may be sent to the second communication agent again, thereby causing unnecessary service administration. In order to solve the problem, the embodiment may determine, through the special microservice list in the user mode protocol, whether the target application of the access request is the special microservice, and may further directly send the access request to the host without passing through the second communication agent under the condition that the target application of the access request is not the special microservice.

Next, with reference to fig. 10 and 5, the scheme of the present embodiment will be described by taking, as an example, the micro service 1111 on the node 100 calling the special micro service 2131 on the node 200.

Microservice 1111 may generate access request a 4. The access request a4 may include a service identification of the service that the particular microservice 2131 may provide. Microservice 1111 may perform step 1001, sending access request A4 to traffic intercept module 114. The traffic intercepting module 114 may determine whether the access request a4 needs to perform service administration by using the list to be administered according to the service identifier in the access request a 4. The service identifier in the access request a4 is the service identifier corresponding to the special micro service 2131, and the service identifier is located in the list to be administered, and it is determined that the access request a4 needs to perform service administration. Thus, the traffic intercept module 114 may perform step 1002, forwarding the access request a4 to the data path 140.

The data path 140 may perform step 1003 to send the access request a4 to the user mode protocol stack 122.

The user mode protocol stack 122 may perform step 1004 of sending an access request a4 to the communication agent 121.

Specifically, reference may be made to the above description of step 701, step 702, step 703 and step 704 for performing step 1001, step 1002, step 1003 and step 1004, which is not described herein again.

The communication agent 121 may perform step 1005 to service the access request a 4. Specifically, the communication agent 121 may perform service governance according to the service identification in the access request a4, according to the service governance policy. Wherein, the service governance may include selecting, through load balancing, an application that provides the service described by the service identifier for the micro service 1111. In this embodiment, the selected application providing the service described by the service identifier for microservice 1111 may be determined as special microservice 2131, that is, the special microservice 2131 is determined as the target application of access request a 4. Illustratively, upon determining that special microservice 2131 is the target application of access request a4, the socket target address of access request a4 may be updated to the network address of special microservice 2131. The special microservice 2131 may be referred to as a target application of the access request a4, and the network address of the special microservice 2131 may be referred to as a target application address of the access request a 4. The network address of special microservice 2131 may refer to the network address of the group of containers running special microservice 2131, i.e., the network address of container group 213. Illustratively, the network address of the container group 213 may include an IP address and a port number of the container group 213.

The communication agent 121 may perform step 1006 to send the access request a4 to the user mode protocol stack 122. The user mode protocol stack 122 may perform step 1007 to determine that the target application of the access request a4 is not located at the node. The user mode protocol stack 122 may then perform step 1008 to add the service grid identification for access request a 4. The service grid identifier may refer to the above description of the embodiment shown in fig. 8, and is not described herein again. The user mode protocol stack 122 may also perform step 1009 of encapsulating the target application address of the access request a 4. As described above, the target application address determined in step 1005 is the network address of the special microservice 2131. It is understood that a particular microservice 2131 resides on a node (i.e., node 200). In step 1009, the network address of the particular microservice 2131 may be encapsulated as the address of the node. For example, the network address of the particular microservice 2131 may be the network address comprising the group of containers 213. The group of containers 213 is located at the node 200, and the network address of the special microservice 2131 may be encapsulated as the IP address of the node 200 in step 1009.

In addition, the execution of step 1006, step 1007, step 1008, and step 1009 can also refer to (3) in fig. 5. Specifically, in step 1006, the access request a4 is sent to the user mode protocol stack 122 as outbound traffic issued by the communication agent 121. The user mode protocol stack 122 may determine that the communication agent 121 is the sender of the outgoing flow according to the data stream sending process UID of the access request a4, and determine that the target application is not located at the local node (node 100) according to the target application address of the access request a 4. The access request a4 may then be subject to service grid identification additions, destination application address encapsulation, and the like.

Next, the user mode protocol stack 122 may execute step 1010 to send an access request a4 to the network card 130. Referring to (4) in fig. 5, when processing traffic to the outside, the network card may be directly transmitted to the network card of the target node through the network. Referring back to fig. 10, in step 1011, the network card 130 may send an access request a4 to the network card 230. Specifically, the network card 130 may send the access request a4 to the network card 230 over the network 300.

Referring to fig. 10, the network card 230 may perform step 1012 to recover the target application address from the access request a 4; and performing step 1013 of determining that access request a4 has a service grid identification. Referring to fig. 5 (10), after receiving the data packet carrying the access request a4, the physical network card of the network card 230 may recover the destination application address of the access request a4 and determine whether the access request a4 has the service grid identifier.

The network card 230 may then perform step 1014 to send the access request a4 to the user mode protocol stack 222. Referring also to (12) of fig. 5, the network card 230 forwards the access request a4 to the user mode protocol stack 222 through a virtual network port between the network card and the data card 220.

The user mode protocol stack 222 may perform step 1015 to determine the target application of the access request a4 as a particular microservice. As described above, during initialization, the user mode protocol stack may obtain a list of special microservices. The special microservice list includes identification information for 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 micro-service according to the network address of the target application, i.e., determine that the network address of the target application is located in the special micro-service list.

After determining that the target application of the access request A4 is a special microservice, the user mode protocol stack 222 may perform step 1016, sending the access request A4 to the data channel 240. The data path 240 may perform step 1017 to send an access request a4 to the traffic intercept module 215. Traffic intercept module 215 may perform step 1018, sending access request a4 to special microservice 2131.

Wherein, the execution of step 1016-step 1018 can refer to (13) in fig. 5, the user mode protocol stack 222 can send the access request a4 directly to the data channel 240 after determining that the target application of the access request a4 is the special microservice 2131. In the case that the access request a4 is a socket connection request, the data channel 240 located at one end of the data card 120 may convert the access request a4 into a data stream under the PCIe protocol when receiving the access request a4, and transmit the data stream under the PCIe protocol to the host 210. When the PCIe data stream arrives at the side of the host 210 where the data channel 240 is located, the PCIe data stream may be converted into an access request a4 in the form of a socket connection request. The system kernel of host 210 may send access request a4 directly to special microservice 2131.

Thus, a connection between microservice 1111 and special microservice 2131 can be established, and call of microservice 1111 to special microservice 2131 can be realized. Illustratively, 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.

In the fifth embodiment, the normal application on the node 200 calls other normal applications on the node 200.

Next, with reference to fig. 11 and fig. 5, the scheme provided in this embodiment will be described by taking the normal application 212 as an example to call the normal application 211.

Referring to fig. 11, the general application 212 may generate an access request a5, the target application address of the access request a5 being the network address of the general application 211. The generic application 212 may perform step 1101 by sending an access request a5 to the traffic interception module 215. The traffic interception module 215 may determine that the target application of the access request a5 is the normal application 211. The traffic intercepting module 215 may perform step 1102 of sending an access request a5 to the generic application 211.

Referring to (17a) in fig. 5, the target application of the access request initiated by the normal application 212 is the normal application 211. The traffic intercepting module 215 in the system kernel of the host 210 may determine that the target application to which the normal application 212 requests connection is the normal application 211 on the host, and may further directly send the access request initiated by the normal application 212 to the normal application 211.

Thus, a connection between the general application 212 and the general application 211 can be established, and the general application 212 can call the general application 211.

In a sixth embodiment, the node 200 forwards the access request of the node 100.

The services grid system may also include a node 500. Due to the limitation of networking, there is no direct communication connection between the node 100 and the node B500, so that it is difficult for the access request from the microservice on the node 100 to be directly transmitted to the node 500. In this case, when the micro service on the node 100 needs to invoke an application (which may be a micro service or a general application) on the node 500, the node 200 may forward the access request sent by the node 100 to the node 500. That is, the node 200 may provide a transit service to serve as a transit node between the node 100 and the node 500. The transit service belongs to a service in the service grid, that is, the transit service may be provided by a certain microservice or microservices. In one example, the transit service may be specifically provided by a communication agent in the node.

Next, the scheme provided in this embodiment will be described with reference to fig. 12 and 5, taking the micro service 1111 as an example for invoking the service on the node 500.

Microservice 1111 may generate access request a6 for requesting an application on calling node 500. For convenience of description, the application on the node 500 that the access request a6 requests to invoke may be referred to as application B. Without a direct communication connection between node 100 and node 500. For access request a6 to be a socket connection request, microservice 1111 may encapsulate the network address of application B in the header of the C1 layer of access request a 6. And identifies the service of the transit service as the destination address of the C2 layer of access request a 6. Wherein, the destination address in the C2 layer is the direct address of the access request a6, and the module or component on the forwarding path of the access request a6 can directly identify the destination address in the C2 layer and route the access request a6 according to the destination address. It can be understood that, in the service grid system, the destination address of the C2 layer set by the microservice 1111 for the access request when the access request is generated is a service identifier, and is not an address of a specific module or component, which is used for identifying that the access request needs to be subjected to service administration, so that the access request can be forwarded to the communication proxy according to the destination address of the C2 layer. Illustratively, the layer C2 may be a transport layer or a fourth layer in a network seven-layer protocol. The C1 layer is a higher layer of the C2 layer, and the C1 layer may be an application layer or a seventh layer in a network seven-layer protocol, for example.

The microservice 1111 may perform step 1201 by sending an access request a6 to the traffic intercept module 114. The traffic interception module 114 may determine that the destination address of the transport layer of the access request a6, i.e., the service identifier of the transit service, is in the need to be administered list, and thus may determine that the access request a6 needs to be administered with the service.

The traffic intercept module 114 may perform step 1202 to forward the access request a6 to the data path 140. The data path 140 may perform step 1203 to send the access request a6 to the user mode protocol stack 122. The user mode protocol stack 122 may perform step 1204 to send an access request a6 to the communication agent 121.

Specifically, the steps 1202, 1203, and 1204 may be executed by referring to the above descriptions of the steps 701, 702, 703, and 704, and the above descriptions of (1) and (2) in fig. 5. And will not be described in detail herein.

The communication agent 121 may perform step 1205 for service administration of the access request a 6. Specifically, the communication agent 121 may perform service policing according to the service identification of the C1 layer of the access request a6 according to the service policing policy to determine the application providing the transit service for the access request a 6. For example, it may be configured that in step 1205, the communication agent 221 in the node 200 determines to provide transit service for the access request a 6. That is, it is determined that the communication agent 221 is the target application of the access request A6 and the network address of the communication agent 221 is the target application address of the access request A6. Thereafter, the communication agent 121 may update the destination address of the C2 layer of the access request A6 to the network address of the communication agent 221. Illustratively, the network address of the communication agent 221 may be specifically the network address of the listening port 3. The communication agent 121 may send the updated access request a6 to the user mode protocol stack 122, via step 1206.

The user mode protocol stack 122 may perform step 1207 to determine that the target application of access request a6 is not located at the node. The user mode protocol stack 122 may perform step 1208 to add the service grid identification for access request a6 and perform step 1209 to encapsulate the target application address of access request a 6. In particular, the network address of the communication agent 221 may be encapsulated into the IP address of the node 200. The user mode protocol stack 122 may also perform step 1210 to send the address encapsulated access request a6 to the portal 130. The network port 130 may perform step 1211 to send the access request a6 to the network card 230.

The network card 230 may perform step 1212 to recover the target application address of the access request a 6; and step 1213 is performed to determine that access request a6 has a service grid identification. The network card 230 may then perform step 1214, sending the access request a6 to the user mode protocol stack 222.

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. The user mode protocol stack 222 may then send the access request a6 to the communication agent 221 via step 1216.

The steps 1205-1216 can be specifically implemented by referring to the above description of step 805 and 816 in fig. 8 and (2), (3), (4), (10), (12), and (14) in fig. 5, and are not described herein again.

Continuing with FIG. 12, the communication agent 221 may perform step 1217 by parsing the C1 layer header of the access request A6 to obtain the network address of application B. The communication agent 221 may skip the service administration of the access request a6 and instead perform step 1218 to update the target application address of the access request a6 to the network address of application B, that is, the target application of the access request a6 to application B. Step 1220 may then be performed to send the updated access request a6 to the user mode protocol stack 222. For example, in step 1220, the communication proxy 221 may call an API of the user mode protocol stack 222 to add a service governance identification for access request a 6.

In step 1217 and 1220, referring to (15) in fig. 5, the communication agent 221 may record the access request a6 as the inbound traffic, and determine that the node 200 is the transit node of the access request a6 according to the content in the access request a6 packet (i.e. the content of the C1 layer). Thus, subsequent service administration is skipped; updating the target application address of access request a6 to the address of application B; and according to the access request A6 as the incoming direction traffic, calling the API of the user mode protocol stack 222 to add the service governance identification for the access request A6.

The user mode protocol stack 222 may perform step 1221 by determining that the target application of the access request a6 is not located at the node (node 200); and step 1222 is performed to encapsulate the target application address of access request a 6. Illustratively, the network address encapsulation of application B may be referred to as the IP address of node 500. In one example, where application B is microservice, the user mode protocol stack 222 may also add a service grid identification to access request a 6. The user mode protocol stack 222 may then send the access request a6 to the network card 230 in step 1223. Network card 230 may perform step 1224 and send access request a6 to node 500.

In step 1221 and 1224, referring to (16) in fig. 5, the user mode protocol stack 222 may determine that the target application of the access request a6 is not located in the node, and determine that the access request a6 is inbound traffic according to the service administration identifier of the access request a 6. The service grid identification may be added to the access request a6, the destination application address encapsulated, and the access request a6 sent through the network card 230 into the network 300 to send the access request a6 through the network 300 to the node 500.

Through the scheme, under the condition that the node and the other node do not have direct communication connection, the other node can be used as a transfer node to realize indirect communication between the nodes.

Seventh, a generic application on node 100 invokes a microservice on node 200.

Under the condition that the common application needs to call the micro service, the method can be realized by configuring the communication proxy as an ingress gateway. Wherein, the ingress gateway may also be referred to as a serving mesh gateway. When the target address of the access request is the service grid gateway address, even if the access request does not include the service grid identifier, the network card can send the access request to the data card, so that the data card can carry out service management on the access request and send the access request to the corresponding micro-service, and calling of the micro-service by common application is realized.

Next, with reference to fig. 13 and fig. 5, a scheme for the general application to invoke the micro service provided in this embodiment is described by taking the general application 113 to invoke the micro service 2141 as an example.

The generic application 113 may generate an access request a7 with the serving grid gateway address of the node 200 as the initial destination address. And the service request a7 may also include a service identification of the service required by the generic application 113. The service identifier may refer to the above description, and is not described herein again. Illustratively, the access request a7 may be a packet, and the service identifier may be encapsulated in a header of an application layer of the packet. Additionally, it will be appreciated that the destination address of access request A7 is typically located at the transport layer.

The generic application 113 may perform step 1301 to send an access request a7 to the network card 130. In this regard, as also shown in fig. 5 (5), when access request a7 passes through traffic interception module 114, traffic interception module 114 determines that its initial destination address is not located in the list to be remediated. Illustratively, its initial target address may be an address at the transport layer. That is, traffic intercept module 114 determines that the address of the transport layer of access request A7 is not located in the need to be administered list. In turn, the traffic interception module 114 may send the access request a7 to the network card 130 through the virtual network port.

Network card 130 may perform step 1302 to encapsulate the initial destination address of access request a 7. Illustratively, the serving mesh gateway address as the initial target address may be the network address of a certain listening port of the communication agent 221. The network address of the listening port may be encapsulated into the IP address of the node 200.

The network card 130 may execute step 1303, and send the access request a7 encapsulated with the initial target address to the network card 230. Specifically, referring to (10) in fig. 5, in step 1303, the access request a7 may enter the network 300 through the physical network card of the network card 130, and may be received by the physical network card of the network card 230 after being forwarded through the network 300.

The network card 230 may perform step 1304 to recover the original target address of the access request a 7. I.e. the serving mesh gateway address is recovered. The network card 230 may perform step 1305, sending the access request a7 to the user mode protocol stack 222. Referring to fig. 5 (17b), (12), network card 230 may determine the initial destination address of access request a7 to be the serving mesh gateway address. In the case where the initial destination address of the access request a7 is the serving grid gateway address, the network card 230 may send the access request a7 to the user mode protocol stack 222 through the virtual portal even though the access request a7 does not have a serving grid identification.

User mode protocol stack 222 may perform step 1306 to determine the initial destination address of access request a7 as the serving grid gateway address. Step 1307 may then be performed to send an access request a7 to the communication agent 221. In one example, referring to (14) in fig. 5, the initial target address may be set to be a network address of the listening port 3 of the communication agent 221. The user mode protocol stack 221 may send access request a7 to snoop port 3 of the communication agent 221 upon determining that the initial target address is not an address of a particular micro-service and that access request a7 does not have a service grid identification.

The communication agent 221 may perform step 1308 of determining the service actually requested by the access request a 7. As described above, the access request a7 carries a service identifier indicating a service required by the general application 113. The service identification may be in the application layer header of access request a 7. The communication proxy 221 may parse the access request a7, e.g., may parse the application layer header of the access request a7, so that the service identification may be obtained. After obtaining the service identification, the communication proxy 221 may perform step 1309 to administer the service to the access request a 7. Specifically, the micro-service for providing the service represented by the service identifier may be determined according to the service identifier by using the service list and the service administration policy. In this embodiment, the determination microservice 2141 may be configured to provide the service represented by the service identifier. The communication agent 211 may then perform step 1310, sending the access request a7 to the user mode protocol stack 222. In step 1308-step 1310, referring to (14) in fig. 5, when the communication agent 221 receives the access request a7 through the listening port 3, it may record that the access request a7 is incoming direction traffic. After service administration of access request A7, when access request A7 is sent to an upstream module or component, the API of user mode protocol stack 222 may be called to add a service administration identification to access request A7.

In this embodiment, the service identifier of a certain service may be simply referred to as the identifier of the service.

User mode protocol stack 222 may perform step 1311, sending access request a7 to microservice 2141. The specific process of step 1311 may refer to the description of step 819 and 821 in fig. 8, and is not described herein again.

Thus, a connection between the general application 113 and the micro service 2141 can be established, and the general application 113 can call the micro service 2141. Illustratively, the access request a7 may specifically be a socket connection request, and the established connection between the general application 113 and the microservice 2141 may be a socket connection.

In an eighth embodiment, the microservice on node 100 invokes a generic application of node 200.

Some common applications in the services grid system may be invoked by microservices. In the embodiment, in order to realize that the ordinary applications can be called by the micro-service, the service identification of the provided service of the ordinary applications can be predefined. Taking service C as an example, the service identifier thereof may be information describing or representing service C. Wherein, the service C may be provided by a general application. The service identification of the service provided by these common applications may be set in the need to administer list. In this embodiment, for convenience of description, the service identifier of the service provided by the general application may be referred to as a service identifier of the general application. Illustratively, the service identification of the generic application may be a network address of the generic application. In one example, the network address of the general application may include an IP address and a port number of the general application.

As described above, the list of treatments required may be preconfigured by the developer or the operation and maintenance personnel of the service grid system. When configuring the need to be managed list, the service identification of the common application which may be called by the micro-service can be added to the need to be managed list. In the case where the need to be managed list includes the service identification of the general application, an access request carrying the service identification of the general application may be sent to the data card so that the service management of the communication agent can be accepted. Thus, the service identification of the common application is used for declaring that the access request needs to be subjected to service administration.

In some embodiments, the service list may also include a correspondence between the service identifier of the common application and the network address, so that the communication agent may determine the network address available for access according to the service identifier. The service list includes types of applications corresponding to the network addresses, and the types of applications may be classified into micro-services and general applications. That is, whether the application corresponding to the network address is a micro service or a general application is recorded in the service list.

The specific configuration of the list to be managed and the service list may refer to the above description of the embodiment shown in fig. 6, and will not be described herein again.

Next, with reference to fig. 14 and fig. 5, a scheme of invoking a general application by a microservice provided in this embodiment is described by taking the microservice 1111 as an example to invoke the general application 211.

When microservice 1111 needs to use the service provided by generic application 211, access request A8 may be generated and the service identification for the service may be the initial target address of access request A8.

The microservice 1111 may perform step 1401, sending an access request A8 to the traffic intercept module 114. The traffic interception module 114 may determine that the initial target address of the access request A8 or the service identifier carried by the access request A8 is located in the need to be governed list, and the traffic interception module 114 may execute step 1402 to send the access request A8 to the data channel 140. The data channel 140 may perform step 1403, sending an access request A8 to the user mode protocol stack 122. The user mode protocol stack 122 may perform step 1404 to send an access request A8 to the communication agent 121. The steps 1401-1404 can be performed as described above with reference to the steps 702-704 in fig. 7 and the descriptions of (1) and (2) in fig. 5, which are not repeated herein.

The communication agent 121 may perform step 1405 for service administration of the access request A8. The method may include determining, according to the service identifier carried in the access request A8, an application that can provide the service described by the service identifier, by using the service list and according to the load balancing policy. The determined application may be set as the normal application 211. Through step 1405, the network address of the normal application 211 is determined as the target application address of the access request A8, and accordingly, the normal application 211 is determined as the target application of the access request A8.

The communication agent 121 may perform step 1406 to add a non-serving grid identification for access request A8. The non-service grid identification is used to indicate that the target application carrying the access request does not belong to the microservice. As described above, the service list records the type of application corresponding to the network address. Upon determining that the network address of the generic application 211 is determined to be the target application address of access request A8, the target application of access request A8 may be determined to be a pervasive application, rather than a microservice in a services grid. Thus, a non-serving grid identification may be added for access request A8. Illustratively, the communication agent 121 may call an API to add a non-service grid identification for access request A8.

After performing step 1406, the communication agent 121 may perform step 1407 of sending an access request A8 to the user mode protocol stack 122.

The user mode protocol stack 122 may perform step 1408, determine that the target application of access request A8 is not located at the node, and determine that access request A8 has a non-serving grid identification. The user mode protocol stack 122 may then perform step 1409 to encapsulate the target application address of the access request A8. Specifically, the destination application address of access request A8 may be encapsulated into the IP address of node 200.

The user mode protocol stack 122 may then send the access request A8 to the network card 130. Upon receiving the access request A8, the network card 130 may perform step 1411 to send an access request A8 to the network card 230.

Network card 230, upon receiving access request A8, may perform step 1412 to recover the target application address of access request A8. Step 1413 and step 1414 may also be performed. Therein, in step 1413, it may be determined that access request A8 does not have a serving grid identification and that access request A8 has a non-serving grid identification. In step 1414, it is determined that the destination application address of access request A8 is not a serving grid gateway address. Thus, the network card 230 may perform step 1415 to send the access request A8 directly to the normal application 211.

Referring also to (11) in fig. 5, in the case that A8 has no service grid id and the target application address of the access request A8 is not the service grid gateway address, the network card 230 no longer sends the access request A8 to the data card 220, but sends the access request A8 directly to the host 210 through the virtual network card, so that the host 210 can send the access request A8 directly to the normal application 211.

Thus, a connection between the microservice 1111 and the normal application 211 is established, and the call of the microservice 1111 to the normal application 211 is realized. Illustratively, the access request A8 may specifically be a socket connection request, and the established connection between the microservice 1111 and the general application 211 may be a socket connection.

As can be seen from the above description, in the embodiment of the present application, the sidecar may be placed to the data card, so that the service invocation in the service grid may be sunk to the data card for processing and sending, thereby not occupying the computing resource of the host, improving the efficiency of service administration, and saving the computing resource of the host. Meanwhile, the client application can be applied to the service grid system provided by the embodiment of the application without modification, so that the service grid system has a high utilization value.

By integrating the above embodiments, the present application also provides a service grid system. Referring to fig. 4, the service system may include a node 100, where the node 100 includes a host 110 and a data card 120, the data card 120 is inserted into the host 110, the data card 120 and the host 110 are provided with a data channel 140, the host 110 runs a first container group, the first container group is provided with a first micro-service, and the data card 120 accesses a network 300.

The data card 120 may receive the service governance policy sent by the governing node through the network 300, and perform service governance on a first access request sent by the host 110 to the data card 120 via the data channel 140 according to the service governance policy, where the first access request is an access request of a first micro service acquired by the host 110 from the first container group for a second micro service. Specifically, reference may be made to the above description of the embodiments shown in fig. 5, fig. 6, and fig. 7, which are not repeated herein.

In some embodiments, the service governance policy includes a correspondence relationship between the second micro service and a network address of a second container group running the second micro service, where the data card 120 is configured to determine, according to the service governance policy, the network address of the second container group running the second micro service, set a destination address of the first access request as the network address of the second container group, and determine that the second container group is set in the host 110, and send the modified first access request to the second container group through the data channel 140. Specifically, reference may be made to the above description of the first embodiment, which is not described herein again.

In some embodiments, the service governance policy further comprises a correspondence of a third microservice to a network address of a third container group running the third microservice; the host 110 is further configured to obtain a second access request of the first micro service for the third micro service from the first container group, and send the second access request to the data card 120 through the data channel 140; and the data card 120 is configured to confirm a network address of a third container group running the third microservice according to the service governance policy, set a destination address of the second access request as the network address of the third container group, confirm that the third container group is not set in the host 110, and send the second access request through the network. Specifically, reference may be made to the above description of the second embodiment, which is not described herein again.

In an example of these embodiments, the node 100 further includes a network card 130, where the network card 130 is connected to the data card 120, and the data card 120 accesses the network through the network card 130, where the data card 120 is configured to send a second access request to the network card 130; and a network card 130 for sending the second access request through the network. Specifically, reference may be made to the above description of the second embodiment, which is not described herein again.

In an example of this example, referring to fig. 4, the service grid system further includes a node 200, where the node 200 includes a host 210, a data card 220, and a network card 230, the data card 220 is inserted into the host 210, the data card 220 and the host 210 are provided with a data channel 240, a third container group runs on the host 210, the network card 230 is connected to the data card 220, and the network card 230 accesses the network, where the data card 120 is further configured to set a service grid identifier for the second access request if it is determined that the third container group is not set in the host 110; the network card 230 is configured to receive a second access request sent by the network card 130, and send the second access request to the data card 220 when it is determined that the second access request carries the service grid identifier; and a data card 220 for sending a second access request to the third container group through the data channel 240 in case that the third container group is set in the host 210. Specifically, reference may be made to the above description of the second embodiment, which is not described herein again.

In some embodiments, the service grid system further includes a node 200, where the node 200 includes a host 210, the host 210 and the host 110 access a network, the host 110 runs a first application, and the host 210 runs a second application, where the host 110 is configured to obtain a third access request of the first application for a network address of the second application, and send the third access request through the network if it is determined that the host 110 does not run the second application; and the host 210 is configured to receive the third access request sent by the host 110, and send the third access request to the second application. Specifically, reference may be made to the above description of the third embodiment, which is not described herein again.

In some embodiments, the host 110 runs the first application and the second application, wherein the host 110 is configured to obtain a 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 is confirmed that the second application runs on the host 110. Specifically, reference may be made to the above description of the fifth embodiment, which is not described herein again.

In some embodiments, the service grid system further includes a node 200, where the node 200 includes a host 210 and a data card 220, the data card 220 is inserted into the host 210, the data card 220 and the host 210 are provided with a data channel 240, a fourth container group runs on the host 210, a fourth micro-service is provided in the fourth container group, the data card 220 and the host 110 access a network, where the host 110 runs a first application, and 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 through the network; the data card 220 is configured to receive a fourth access request sent by the host 110, and send the fourth access request to a fourth micro service through the data channel 240 according to an identifier of the fourth micro service carried in the fourth access request. Specifically, reference may be made to the above description of the seventh embodiment, which is not described herein again.

In some embodiments, the service grid system further includes a node 200, where the node 200 includes a host 210, the host 210 runs a third application, and the host 210 accesses the network, where the host 110 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 data card 120 through the data channel 140; a data card 120 for sending a fifth access request through the network; and the host 210 is configured to receive the fifth access request and send the fifth access request to the third application. Specifically, reference may be made to the above description of the eighth embodiment, which is not described herein again.

Referring to fig. 15, an embodiment of the present application provides a data processing method. The method may be applied to the services grid system shown in figure 4. As shown in fig. 15, the method includes the following steps.

In step 1501, the data card 120 receives a service administration policy sent by the management and control node through the network.

At step 1502, data card 120 performs service administration on the first access request sent by host 110 to data card 120 via data channel 140 according to the service administration policy. Wherein the first access request is an access request of a first micro-service to a second micro-service acquired by the host 110 from a first container group.

Specifically, reference may be made to the above description of the embodiments shown in fig. 5, fig. 6, and fig. 7, which are not repeated herein.

In some embodiments, the service governance policy comprises a correspondence of the second micro-service to a network address of a second set of containers running the second micro-service; step 1502 includes: the data card 120 confirms the network address of the second container group running the second micro-service according to the service governance policy, and sets the destination address of the first access request as the network address of the second container group; the data card 120 confirms that the second container group is set in the host 110 and sends the modified first access request to the second container group through the data channel 140. Specifically, reference may be made to the above description of the first embodiment, which is not described herein again.

In some embodiments, the service governance policy further comprises a correspondence of a third microservice to a network address of a third container group running the third microservice; the method further comprises the following steps: the host 110 acquires a second access request of the first micro-service for the third micro-service from the first container group, and sends the second access request to the data card 120 through the data channel 140; the data card 120 confirms the network address of a third container group running a third micro service according to the service administration policy, and sets the destination address of the second access request as the network address of the third container group; the data card 120 confirms that the third container group is not set in the host 110 and transmits a second access request through the network. Specifically, reference may be made to the above description of the second embodiment, which is not described herein again.

In one example of these embodiments, the node 100 further includes a network card 130, the network card 130 is connected to the data card 120, and the data card 120 accesses the network through the network card 130; the data card 120 confirms that the third container group is not set in the host 110, and transmits a second access request through the network, including: the data card 120 determines that the third container group is not set in the host 110, and sends a second access request to the network card 130; network card 130 sends a second access request over the network. Specifically, reference may be made to the above description of the second embodiment, which is not described herein again.

In an example of this example, the service grid system further includes a node 200, where the node 200 includes a host 210, a data card 220, and a network card 230, the data card 220 is inserted into the host 210, the data card 220 and the host 210 are provided with a data channel 240, a third group of containers runs on the host 210, the network card 230 is connected to the data card 220, and the network card 230 is connected to the network; the method further comprises the following steps: the data card 120 sets a service grid identifier for the second access request in case it is confirmed that the third container group is not set at the host 110; the network card 230 receives the second access request sent by the network card 130, and sends the second access request to the data card 220 under the condition that the second access request carries the service grid identifier; in the event that the data card 220 confirms that the third container group is set to the host 210, a second access request is sent to the third container group via the data channel 240. Specifically, reference may be made to the above description of the second embodiment, which is not described herein again.

In some embodiments, the service grid system further comprises a node 200, the node 200 comprising a host 210, the host 210 and the host 110 accessing the network, the host 110 having a first application running thereon, the host 210 having a second application running thereon; the method further comprises the following steps:

the host 110 acquires a third access request of the first application for the network address of the second application, and sends the third access request through the network when the host 110 is confirmed not to run the second application; the host 210 receives the third access request sent by the host 110 and sends the third access request to the second application. Specifically, reference may be made to the above description of the third embodiment, which is not described herein again.

In some embodiments, the host 110 has a first application and a second application running thereon; the method further comprises the following steps: the host 110 obtains a third access request of the first application for the network address of the second application, and sends the third access request to the second application when the host 110 is determined to run the second application. Specifically, reference may be made to the above description of the fifth embodiment, which is not described herein again.

In some embodiments, the service grid system further includes a node 200, where the node 200 includes a host 210 and a data card 220, the data card 220 is inserted into the host 210, the data card 220 and the host 210 are provided with a data channel 240, a fourth group of containers is run on the host 210, a fourth micro-service is provided in the fourth group of containers, the data card 220 and the host 110 access the network, and the host 110 runs a first application; the method further comprises the following steps: the host 110 acquires a fourth access request of the first application for the network address of the data card 220, and sends the fourth access request through 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 micro service through the data channel 240 according to the identifier of the fourth micro service carried in the fourth access request. Specifically, reference may be made to the above description of the seventh embodiment, which is not described herein again.

In some embodiments, the services grid system further comprises a node 200, the node 200 comprising a host 210, the host 210 having a third application running thereon, the host 210 having access to the network; the method further comprises the following steps: the host 110 obtains a fifth access request of the first microservice for the network address of the third application, and sends the fifth access request to the data card 120 through the data channel 140; the data card 120 sends a fifth access request through the network; the host 210 receives the fifth access request and sends the fifth access request to the third application. Specifically, reference may be made to the above description of the eighth embodiment, which is not described herein again.

Referring to fig. 16, the embodiment of the present application further provides a network node 1600, which includes a host 1610 and a data card 1620. Data card 1620 is plugged into host 1610. Illustratively, as shown in FIG. 16, data card 1620 is inserted into host 1610 via a PCIe interface.

Host 1610 may include a processor 1611 and a memory 1612. Memory 1612 stores computer instructions that are executable by processor 1611. The data card 1620 may include a processor 1621 and a memory 1622. Stored in the memory 1622 are computer instructions that are executable by the processor 1621. Wherein, when the computer instructions stored by memory 1612 are executed by processor 1611 and the computer instructions stored by memory 1622 are executed by processor 1621, network node 1600 may perform the operations performed by node 100 or node 200 in the embodiments shown in fig. 5-15.

It is understood that the processor in the embodiments of the present application may be a Central Processing Unit (CPU), other general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, a transistor logic device, a hardware component, or any combination thereof. The general purpose processor may be a microprocessor, but may be any conventional processor. It is to be understood that the various numerical references referred to in the embodiments of the present application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of the present application.

Claims

1. A microservice-based services grid system comprising a first node, said first node comprising a first host and a first data card, the first data card is inserted in the first host, a first data channel is arranged between the first data card and the first host, the first host runs a first container group, the first container group is provided with a first micro-service, the first data card is accessed to the network, receiving a service governance policy sent by a management and control node through the network, and performing service governance on a first access request sent by the first host to the first data card through the first data channel according to the service governance policy, wherein the first access request is an access request of the first micro-service for a second micro-service acquired by the first host from the first container group.

2. The services grid system of claim 1, wherein said service governance policy comprises a correspondence of said second micro-service to a network address of a second set of containers running said second micro-service, wherein,

the first data card is configured to confirm a network address of a second container group running the second micro service according to the service administration policy, set a destination address of the first access request as the network address of the second container group, confirm that the second container group is set in the first host, and send the modified first access request to the second container group through the first data channel.

3. The services grid system of claim 1, wherein the service governance policy further comprises a correspondence of a third microservice to a network address of a third set of containers running the third microservice;

the first host is further configured to obtain a second access request of the first micro service for a third micro service from the first container group, and send the second access request to the first data card through the first data channel;

the first data card is configured to confirm, according to the service administration policy, a network address of a third container group in which the third micro service is operated, set a destination address of the second access request as the network address of the third container group, confirm that the third container group is not set in the first host, and send the second access request through the network.

4. The serving grid system of claim 3, wherein the first node further comprises a first network card, the first network card connected to the first data card, the first data card accessing the network through the first network card, wherein,

the first data card is used for sending the second access request to the first network card;

the first network card is used for sending the second access request through the network.

5. The service grid system according to claim 4, further comprising a second node, said second node comprising a second host, a second data card and a second network card, said second data card being inserted into said second host, said second data card and said second host being provided with a second data channel, said second host having said third set of containers running thereon, said second network card being connected to said second data card, and said second network card being connected to said network, wherein,

the first data card is further used for setting a service grid identifier for the second access request under the condition that the third container group is not set in the first host;

the second network card is configured to receive the second access request sent by the first network card, and send the second access request to the second data card when it is determined that the second access request carries the service grid identifier;

and the second data card is configured to send the second access request to the third container group through the second data channel when it is determined that the third container group is set in the second host.

6. The services grid system of any of claims 1-5, further comprising a third node, said third node comprising a third host, said third host and said first host having access to said network, said first host having a first application running thereon, said third host having a second application running thereon, wherein,

the first host is configured to obtain a third access request of the first application for the network address of the second application, and send the third access request through the network when it is determined that the second application is not running on the first host;

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.

7. The services grid system of any of claims 1-5, wherein said first host has a first application and a second application running thereon, wherein,

the first host is configured to obtain a 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 the first host is determined to run the second application.

8. The service grid system according to any of claims 1-5, further comprising a third node, wherein said third node comprises a third host, a third data card, said third data card is inserted into said third host, said third data card and said third host are provided with a third data channel, said third host runs a fourth container group, said fourth container group is provided with a fourth micro-service, said third data card and said first host access said network,

the first host has a first application running thereon, wherein,

the first host is used for acquiring a fourth access request of the first application for the network address of the third data card and sending the fourth access request through the network;

the third data card is configured to receive the fourth access request sent by the first host, and send the fourth access request to the fourth micro service through the third data channel according to the identifier of the fourth micro service carried in the fourth access request.

9. The services grid system of any of claims 1-5, further comprising a third node, said third node comprising a third host, said third host having a third application running thereon, said third host having access to said network, wherein,

the first host is used for acquiring a fifth access request of the first microservice for a network address of a third application and sending the fifth access request to the first data card through the first data channel;

the first data card is used for sending the fifth access request through a network;

and the third host is used for receiving the fifth access request and sending the fifth access request to the third application.

10. A micro-service-based service governance method is applied to a micro-service-based service grid system, the service grid system comprises a first node, the first node comprises a first host and a first data card, the first data card is inserted in the first host, a first data channel is arranged between the first data card and the first host, a first container group runs on the first host, a first micro-service is arranged in the first container group, and the first data card is accessed to a network;

the method comprises the following steps:

the first data card receives a service management strategy sent by a management and control node through the network;

and the first data card performs service governance on a first access request sent by the first host to the first data card through the first data channel according to the service governance policy, wherein the first access request is an access request of the first micro-service acquired by the first host from the first container group for a second micro-service.

11. The method of claim 10, wherein the service governance policy comprises a correspondence of the second microservice to a network address of a second set of containers running the second microservice;

the first data card performs service governance on a first access request sent by the first host to the first data card through the first data channel according to the service governance policy, and the service governance method includes:

the first data card confirms a network address of a second container group for operating the second micro service according to the service governance strategy, and sets a destination address of the first access request as the network address of the second container group;

and the first data card confirms that the second container group is arranged in the first host, and sends the modified first access request to the second container group through the first data channel.

12. The method of claim 10, wherein the service governance policy further comprises a correspondence of a third microservice to a network address of a third set of containers running the third microservice;

the method further comprises the following steps:

the first host acquires a second access request of the first micro service for a third micro service from the first container group and sends the second access request to the first data card through the first data channel;

the first data card confirms a network address of a third container group for operating the third micro service according to the service governance strategy, and sets a destination address of the second access request as the network address of the third container group;

and the first data card confirms that the third container group is not arranged in the first host, and sends the second access request through the network.

13. The method of claim 12, wherein the first node further comprises a first network card, the first network card connected to the first data card, the first data card accessing the network through the first network card;

the first data card confirming that the third container group is not set in the first host, and sending the second access request through the network, including:

the first data card confirms that the third container group is not arranged on the first host, and sends the second access request to the first network card;

and the first network card sends the second access request through the network.

14. The method of claim 13, wherein the service grid system further comprises a second node, the second node comprises a second host, a second data card and a second network card, the second data card is inserted into the second host, the second data card and the second host are provided with a second data channel, the second host runs the third set of containers, the second network card is connected with the second data card, and the second network card is connected to the network;

the method further comprises the following steps:

setting a service grid identifier for the second access request by the first data card under the condition that the third container group is not set in the first host;

the second network card receives the second access request sent by the first network card, and sends the second access request to the second data card under the condition that the second access request is confirmed to carry the service grid identifier;

and the second data card sends the second access request to the third container group through the second data channel under the condition that the third container group is confirmed to be arranged in the second host.

15. The method of any of claims 10-14, wherein the services grid system further comprises a third node, the third node comprising a third host, the third host and the first host having access to the network, the first host having a first application running thereon, the third host having a second application running thereon;

the method further comprises the following steps:

the first host acquires a third access request of the first application for the network address of the second application, and sends the third access request through the network under the condition that the first host does not operate the second application;

and the third host receives the third access request sent by the first host and sends the third access request to the second application.

16. The method of any of claims 10-14, wherein a first application and a second application are running on the first host;

the method further comprises the following steps:

and the first host acquires a third access request of the first application for the network address of the second application, and sends the third access request to the second application under the condition that the first host is confirmed to run the second application.

17. The method according to any one of claims 10-14, wherein the service grid system further comprises a third node, the third node comprises a third host, a third data card, the third data card is inserted into the third host, the third data card and the third host are provided with a third data channel, the third host runs a fourth container group, the fourth container group is provided with a fourth micro-service, the third data card and the first host access the network, and the first host runs a first application;

the method further comprises the following steps:

the first host acquires a fourth access request of the first application for the network address of the third data card and sends the fourth access request through the network;

and the third data card receives the fourth access request sent by the first host, and sends the fourth access request to the fourth micro service through the third data channel according to the identifier of the fourth micro service carried by the fourth access request.

18. The method of any of claims 10-14, wherein the services grid system further comprises a third node, the third node comprising a third host, a third application running on the third host, the third host accessing the network;

the method further comprises the following steps:

the first host acquires a fifth access request of the first micro-service for a network address of a third application, and sends the fifth access request to the first data card through the first data channel;

the first data card sends the fifth access request through a network;

and the third host receives the fifth access request and sends the fifth access request to the third application.