Patent ID: 12200082

DESCRIPTION OF EMBODIMENTS

The following describes the solutions in embodiments provided in this application with reference to the accompanying drawings in this application.

In the specification, claims, and accompanying drawings of this application, the terms “first”, “second”, and so on are intended to distinguish between similar objects but do not necessarily indicate an order or sequence. It should be understood that the terms used in such a way are interchangeable in appropriate circumstances. This is merely a discrimination manner that is used when objects having a same attribute are described in embodiments of this application.

To facilitate understanding of the technical solutions in this application, the following describes some technical terms in this application.

A microservice is a small service including a single application. Each microservice has its own process and can communicate with another microservice through a lightweight communication mechanism, such as an application programming interface (API) based on the hypertext transfer protocol (HTTP).

A microservice architecture is an architecture that splits an application (especially a large-scale application, such as an e-commerce system) into several microservices. In some examples, the microservice architecture may include a classic architecture such as Spring Cloud or Dubbo with low intrusiveness. Compared with a conventional monolithic architecture that integrates all functional services in one container, the microservice architecture implements service decoupling by decomposing functions into discrete services. Service teams separately maintain microservices corresponding to respective services. This reduces maintenance complexity and improves maintenance efficiency. In addition, when a single microservice is faulty, another microservice can still work. This improves system stability.

In some cases, there may be a call relationship between a plurality of microservices of an application. For example, in an e-commerce system, a microservice of a commodity system may further call a microservice of an evaluation system, to display a historical evaluation of a user on a commodity when commodity details are displayed. Service governance is to process a service call relationship in a distributed service framework. Service governance may be divided into the following parts: service registration and discovery, load balancing, fault handling and recovery (rate limiting, circuit breaker, timeout, and retry), gray release, service tracing, and the like.

Currently, an application based on the microservice architecture mainly implements service governance by using a service mesh. The service mesh is an infrastructure layer used to process communication between services (including microservices). An implementation of the service mesh is to allocate an independent proxy to each microservice. The proxy is also referred to as a side car. The proxy is responsible for processing communication, monitoring, and some security-related work between services, to provide functions such as service discovery, load balancing, encryption, identity authentication, authorization, and circuit breaker. The microservice is no longer responsible for processing logic of a service request, for example, performing load balancing based on a service request, but needs to complete only service processing.

For a large-scale application, one physical machine usually runs containers of a plurality of proxies, for example, containers of hundreds of proxies. However, a quantity of processes of the hundreds of proxies is far greater than a quantity of central processing unit (CPU) cores of the physical machine. When a CPU becomes a system bottleneck due to heavy concurrent request pressure, frequent process context switching is inevitably caused because a plurality of processes contend for the CPU. As a result, a service call delay is sharply increased, and application performance is reduced.

Therefore, an embodiment of this application provides a microservice call method. In the method, a network interface card is used to replace a proxy of a microservice, and functions to be implemented by distributed proxies are implemented together by the network interface card. The network interface card may receive a service call request generated by at least one first service deployed on a device (which is referred to as a first device in this application). Each of a plurality of first services is corresponding to one second service. The second service is used to process first data of a service call request generated by the first service corresponding to the second service. Then, the network interface card may send the service call request to the second service based on service governance logic related to the first data, to implement microservice calling.

In the foregoing method, functions such as service discovery, load balancing, encryption, identity authentication, authorization, and circuit breaker are decoupled from the microservice by using the network interface card, and low intrusiveness is maintained. In addition, the network interface card can process service call requests of different services together. This avoids a sharp increase in a service delay caused when proxies of different services contend for system resources including a CPU, and improves application performance.

In addition, functions implemented by proxies of different services are centralized on the network interface card. This reduces application complexity and facilitates operation and maintenance, and management and control of the application. Further, performing centralized processing by using the network interface card can implement traffic check in batches. In this way, overheads of interaction with a governance center in terms of data are reduced, and concurrency pressure of the governance center in terms of management is reduced. Certainly, performing centralized processing by using the network interface card can also report logs in batches. In this way, overheads of interaction with a data collection center in terms of data are reduced, and concurrency pressure of the data collection in terms of management is reduced.

FIG.1shows a possible application scenario according to an embodiment of this application. In this application scenario, a device104and a device124are network interface cards. The device104is programmable, and may be programmed to implement customized processing logic, for example, implement processing logic for a service call request. Certainly, the device124may also be programmable. In actual application, the device104may be a smart network interface card (smart NID), and the device124may be a common network interface card or a smart network interface card. The smart network interface card is a programmable network interface card, and the common network interface card is not a programmable network interface card.

A device102and a device122are computing devices. The computing device may be a physical machine, or may be a virtual machine obtained after virtualization. In actual application, the device102and the device122may be servers or cloud servers. A plurality of microservices are deployed on the device102and the device122. Microservices deployed on the device102include a service11, a service12, . . . , and a service1n. Microservices deployed on the device122include a service21, a service22, . . . , and a service2n.

In this application scenario, there may further be a device142, a device162, and a device182. Similarly, the device142, the device162, and the device182are computing devices, and the computing device may be a server or a cloud server. A registration center1420is deployed on the device142. The registration center1420records a mapping relationship between a service and a service address. When a microservice calls another microservice, a service address of the called service may be obtained from the registration center1420for service calling. A governance center1620is deployed on the device162, and the governance center1620records a service governance rule. When a microservice calls another microservice, the service governance rule may be obtained from the governance center1620, and service governance logic is run based on the service governance rule. A data collection center1820is deployed on the device182, and the data collection center1820records a service call log. When a microservice is faulty, an operation and maintenance engineer may perform troubleshooting and maintenance based on the service call log.

In this scenario, a microservice on the device102is a service caller, and a microservice on the device122is a service callee. For ease of differentiation, the device102may also be referred to as a first device, and the device122may also be referred to as a second device.

During implementation, a plurality of microservices (which are referred to as first services in this application) deployed on the device102may separately generate service call requests. Each first service is corresponding to one second service. The second service is used to process first data of a service call request generated by the first service corresponding to the second service. Then, the first services separately send the service call requests. A microservice call apparatus1040is deployed on the device104connected to the device102. The microservice call apparatus1040is configured to receive a service call request generated by each of the plurality of first services such as the service11, the service12, . . . , and the service1ndeployed on the device102, and then send the service call request to the second service based on service governance logic related to the first data.

A microservice call apparatus1240is deployed on the device124. The microservice call apparatus1240receives the service call request sent by each of the plurality of first services, and then sends the service call request to the second service deployed on the device122. In response to the service call request, the second service processes first data of the service call request generated by the first service corresponding to the second service, to obtain second data. The second service may generate a service call response based on the second data, and send the service call response to the microservice call apparatus1240. When receiving the service call response, the microservice call apparatus1240sends the service call response to the first service to implement microservice calling.

In actual application, the microservice call apparatus1040deployed on the device104may further send a service provider list change subscription request to the device142. In this way, when a service provider changes, the registration center1420deployed on the device142may send a change message for a service provider list to the microservice call apparatus1040deployed on the device104. In this way, when determining, from the service provider list, an address of the second device providing the second service, the microservice call apparatus1040on the device104may determine, based on a changed service provider list, the address of the second device providing the second service. This avoids sending a service call request to an invalid service provider, and improves service reliability.

Similarly, the microservice call apparatus1040deployed on the device104may further send a service governance rule change subscription request to the device162. In this way, when the service governance rule changes, the governance center1620on the device162may send a change message for the service governance rule to the microservice call apparatus1040deployed on the device104. In this way, when running the service governance logic for the first data according to the service governance rule, the microservice call apparatus1040on the device104may run the service governance logic for the first data according to a changed service governance rule, to perform service governance.

It should be further noted that the foregoing scenario is described merely by using an example in which the microservice deployed on the device102is a service caller, and the microservice deployed on the device122is a service callee. In some implementations, the microservice deployed on the device122may alternatively be used as a service caller. When the microservice deployed on the device122is used as the service caller, the microservice call apparatus1240has a structure similar to that of the microservice call apparatus1040. In addition, the microservice deployed on the device102may alternatively be used as a service callee. This is not limited in this embodiment of this application.

To facilitate understanding of the technical solutions of this application, the following describes a microservice call method in embodiments of this application from a perspective of interaction between the first service, the microservice call apparatus1040, the microservice call apparatus1240, the second service, the registration center1420, the governance center1620, and the data collection center1820.

FIG.2is a flowchart of a microservice call method, and the method includes the following steps.

S202: The microservice call apparatus1040subscribes to a change message for a service provider list.

The microservice call apparatus1040deployed on the device104may send a service provider list change subscription request to the registration center1420on the device142. The service provider list change subscription request is used to request to subscribe to the change message for the service provider list. The service provider list change subscription request includes an identifier of the device104. The registration center1420receives the service provider list change subscription request, and may add the identifier of the device104to a subscriber list. When the service provider list changes, the registration center1420may send the change message for the service provider list to a subscriber in the subscriber list. In this way, the microservice call apparatus1040deployed on the device104may obtain the change message for the service provider list.

It should be understood that in some embodiments, S202may not be performed when the microservice call method is performed. For example, the microservice call apparatus1040may pre-obtain the service provider list, and perform a subsequent operation based on the pre-obtained service provider list.

S204: The microservice call apparatus1040subscribes to a change message for a service governance rule.

Service governance refers to processing of a service call relationship in a distributed service framework, and includes service registration and discovery, load balancing, fault handling and recovery (rate limiting, circuit breaker, timeout, and retry), gray release, service tracing, and the like. Based on this, the governance center1620may define a rule for service governance, that is, the service governance rule. The service governance rule may include a load balancing rule, a fault handling and recovery rule, and the like.

During implementation, the microservice call apparatus1040deployed on the device104may send a service governance rule change subscription request to the governance center1620on the device162. The service governance rule change subscription request is used to request the change message for the service governance rule. Similarly, the service governance rule change subscription request includes the identifier of the device104. When receiving the service governance rule change subscription request, the governance center1620adds the identifier of the device104to a subscriber list. When the service governance rule changes, the governance center1620may send the change message for the service governance rule to a subscriber in the subscriber list. In this way, the microservice call apparatus1040deployed on the device104may obtain the change message for the service governance rule.

It should be noted that the subscriber list maintained by the governance center1620is a subscriber list for the service governance rule, and the subscriber list maintained by the registration center1420is a subscriber list for a service provider address. That is, the governance center1620and the registration center1420maintain different subscriber lists.

It should be understood that in some embodiments, S204may not be performed when the microservice call method is performed. For example, the microservice call apparatus1040may pre-obtain the service governance rule, and perform a subsequent operation based on the pre-obtained service governance rule.

S206: A plurality of first services deployed on the device102separately send service call requests.

Each of the plurality of first services (for example, the service11, the service12, . . . , and the service1nshown inFIG.1) is corresponding to one second service. The second service is used to process first data of a service call request generated by the first service corresponding to the second service.

It should be noted that the first data is data that needs to be processed by the second service. First data that needs to be processed by all services initiating service call requests may be the same or may be different. This may be determined according to an actual requirement. Similarly, second services requested by the first services initiating the service call requests may be the same or may be different. This is not limited in this embodiment of this application.

S208: The microservice call apparatus1040determines, based on service governance logic related to the first data, an address of a second device providing the second service.

The service call request sent by the first service passes through the device104. When receiving the service call request, the microservice call apparatus1040deployed on the device104may unload data of the service call request to obtain the first data. The first data includes at least a header of a data packet. In some cases, the first data may further include a body of the data packet. Then, the microservice call apparatus1040runs, based on the subscribed change message for the service governance rule in S204, the service governance logic for the first data by using a latest (that is, latest changed) service governance rule, to determine, from the service provider list, the address of the second device providing the second service.

It should be noted that when running the service governance logic for the first data to determine, from the service provider list, the address of the second device providing the second service, the microservice call apparatus1040may determine, from a latest (that is, latest changed) service provider list based on the subscribed change message for the service provider list in S202, the address of the second device providing the second service.

It should be understood that when S202is not performed in the microservice call method, the microservice call apparatus1040may determine, based on the pre-obtained service provider list, the address of the second device providing the second service. When S204is not performed in the microservice call method, the microservice call apparatus1040may run the service governance logic for the first data according to the pre-obtained service governance rule.

That the microservice call apparatus1040runs the service governance logic for the first data according to the service governance rule is performing service governance on the first data according to the service governance rule. For ease of understanding, this application further provides an example for description. In an example, as shown inFIG.3, in an application scenario of an e-commerce system, a microservice, that is, a service11, in a commodity system initiates a service call request, and the service call request indicates to process data of a commodity A by using an evaluation obtaining service, that is, a service21, in an evaluation system, to obtain a historical evaluation on the commodity A. Devices that provide the evaluation obtaining service include a device1in East China, a device2in North China, a device3in South China, and a device4in Central China. Traffic load of the device1and traffic load of the device2are higher than traffic load of the device3and traffic load of the device4, and the traffic load of the device4is the lowest. In this case, the microservice call apparatus1040on a smart network interface card determines, according to a load balancing rule, that an address of the device4is an address of a device that finally provides the evaluation obtaining service, and sends the service call request to a service at the address.

In actual application, the microservice call apparatus1040may create a worker thread, and implement, by using the worker thread, the operation of running the service governance logic to determine, from the service provider list, the address of the second device providing the second service.

S210: The microservice call apparatus1040sends a traffic check request to the governance center1620.

During implementation, the microservice call apparatus1040may add the service call request and the address of the corresponding second device to a traffic check queue. The traffic check queue is a blocking queue. Then, the microservice call apparatus1040may send the traffic check request to the governance center1620in batches.

The microservice call apparatus1040may create a checker thread, that is, a checker thread. The checker thread may extract, from the traffic check queue, all service call requests (a plurality of service call requests initiated by a plurality of services deployed on the device102) waiting for traffic check, generate a traffic check request, and send the traffic check request to the governance center1620. In this way, the service call requests are sent to the governance center1620in batches.

S212: The microservice call apparatus1040receives a traffic check response returned by the governance center1620. When a traffic check result in the traffic check response indicates that the check succeeds, S214is performed.

The governance center1620may perform traffic check in batches for a plurality of service call requests in the traffic check request sent by the microservice call apparatus1040, for example, may determine, by checking a source address or the like, whether the service call request is normal traffic or abnormal traffic generated by an attack performed by an outlaw. Then, the governance center1620may generate the traffic check response based on the traffic check result, and return the traffic check response to the microservice call apparatus1040.

It should be noted that, after the microservice call apparatus1040receives the traffic check response returned by the governance center1620, the checker thread may further wake up a worker thread corresponding to this batch of service call requests, and then block a new service call request (that is, a service call request that has not been sent to the governance center1620) waiting in the traffic check queue.

When the traffic check result in the traffic check response received by the microservice call apparatus1040indicates that the check succeeds, the microservice call apparatus1040may perform a subsequent operation, for example, perform S214. When the traffic check result in the traffic check response received by the microservice call apparatus1040indicates that the check fails, the microservice call apparatus1040may end the current microservice call procedure.

It should be understood that S210and S212are only optional implementations for improving security. In some embodiments, neither S210nor S212may be performed when the microservice call method is performed. In other words, the microservice call apparatus1040may perform S214after performing S208.

S214: The microservice call apparatus1040sends the service call request to the second service based on the address of the second device.

After determining the address of the second device providing the second service, the microservice call apparatus1040may set a destination address in the service call request to the address of the second device providing the second service, that is, the device122, and then send the service call request to the second service.

S208and S214are an implementation in which the microservice call apparatus1040on the network interface card sends the service call request to the second service based on the service governance logic related to the first data. In another possible implementation of this embodiment of this application, the microservice call apparatus1040may send the service call request to the second service in another manner.

It should be noted that when the address, determined in S208, of the second device providing the second service is different from a destination address of the service call request in S206, the service call request sent by the microservice call apparatus1040in S214is different from the service call request sent in S206. A main difference lies in that the destination address of the service call request sent in S214is the address, re-determined in S208, of the second device providing the second service. Certainly, in some cases, a packet body of the service call request sent in S214may also be different from a packet body of the service call request sent in S206.

S216: The microservice call apparatus1240sends the service call request to the second service when receiving the service call request.

The service call request sent by the microservice call apparatus1040to the second service passes through the device124. When receiving the service call request, the microservice call apparatus1240deployed on the device124sends the service call request to the second service. It should be noted that, in consideration of network heterogeneity, when receiving the service call request, the microservice call apparatus1240may first unload the service call request, then regenerate a service call request based on unloaded data, and then send the regenerated service call request to the second service.

S218: The second service returns a service call response.

When receiving the service call request, the second service may process the first data in response to the service call request, to obtain second data. For example, if the service call request indicates the evaluation obtaining service in the evaluation system to process the commodity A to obtain the historical evaluation on the commodity A, the evaluation obtaining service may obtain the historical evaluation on the commodity A from all historical evaluations in response to the service call request.

The second service may generate the service call response according to the second data, where the service call response carries the second data, and then the second service returns the service call response.

S220: The microservice call apparatus1240sends the service call response to the microservice call apparatus1040when receiving the service call response.

The service call response returned by the second service passes through the device124. When receiving the service call response, the microservice call apparatus1240deployed on the device124sends the service call response to the microservice call apparatus1040. It should be noted that, similar to the service call request, when receiving the service call response, the microservice call apparatus1240may first unload the service call response, then regenerate a service call response based on unloaded data, and send the regenerated service call response to the microservice call apparatus1040, so that the microservice call apparatus1040can identify the service call response.

S222: The microservice call apparatus1040sends the service call response to the first service corresponding to the second service.

When receiving the service call response, the microservice call apparatus1040may unload the service call response, then regenerate a service call response based on unloaded data, and send the regenerated service call response to the first service.

In this way, the first service calls the second service. It should be noted that service governance is completed on the device104, and there is no intrusion into service logic. For example, when gray release is performed on the second service, neither call logic of the first service nor implementation logic of the second service needs to be modified, and gray release processing logic only needs to be completed on the device104.

S224: The microservice call apparatus1040sends a service call log to the data collection center1820.

In some possible implementations, the microservice call apparatus1040deployed on the device104may further generate the service call log based on at least one of the received service call request and the received service call response, and then send the service call log to the data collection center1820in batches. The microservice call apparatus1040may further set a log uploading cycle. In this way, the microservice call apparatus1040may send the service call log to the data collection center1820in batches based on the preset log uploading cycle.

S226: The microservice call apparatus1240sends a service call log to the data collection center1820.

In some possible implementations, the microservice call apparatus1240deployed on the device124may further generate the service call log based on at least one of the received service call request and the received service call response, and then send the service call log to the data collection center1820in batches based on a preset cycle.

The microservice call apparatus1040and the microservice call apparatus1240upload the service call logs in batches, so that overheads of interaction between the device104and the data collection center1820in terms of data can be reduced, and overheads of interaction between the device124and the data collection center1820in terms of data can be reduced. This reduces costs.

The microservice call apparatus1040generates the service call log based on the received service call request and service call response, and the microservice call apparatus1240generates the service call log based on the received service call request and service call response, so that the data collection center1820can obtain complete log tracing data, including a time at which the first service initiates the service call request, a time at which the second service receives the service call request, a time at which the second service completes processing, and a time at which the first service receives the service call response. When some microservices are faulty, troubleshooting and maintenance can be performed based on the complete log tracing data.

It should be understood that S224and S226are merely optional implementations provided in this embodiment of this application. In some embodiments, neither S224nor S226may be performed when the microservice call method is performed.

InFIG.2, steps identified by using dashed lines or dashed-line boxes are optional steps provided in this embodiment of this application. In some possible implementations, these steps may not be performed, or may be implemented in another manner. This is not limited in this embodiment of this application.

Based on the foregoing content description, in the microservice call method provided in this embodiment of this application, a network interface card is used to replace a proxy in a service mesh, and the network interface card processes together service call requests initiated by different services deployed on one device, to complete service governance. This avoids intrusion into service logic. In addition, the network interface card may process together service call requests initiated by different services. This avoids a problem of a sharp increase in a delay caused by contention of different services for a system resource including a CPU, reduces resource usage of an application, improves application response efficiency, and further improves application performance.

The foregoing describes in detail the microservice call method provided in embodiments of this application with reference toFIG.1toFIG.3. The following describes, with reference to the accompanying drawings, a microservice call apparatus and a corresponding device provided in embodiments of this application.

FIG.4is a schematic diagram of a structure of a microservice call apparatus, and the microservice call apparatus1040includes:a communications module1042, configured to receive service call requests separately generated by a plurality of first services deployed on a first device, where each of the plurality of first services is corresponding to one second service, and the second service is used to process first data of a service call request generated by the first service corresponding to the second service.

The communications module1042is further configured to send the service call request to the second service based on service governance logic related to the first data.

In some possible implementations, the communications module1042is configured to:determine, based on the service governance logic related to the first data, an address of a second device providing the second service; andsend the service call request to the second service based on the address of the second device.

In some possible implementations, the communications module1042is further configured to:send a traffic check request to a governance center, where the traffic check request is used to perform traffic check for N service call requests, and N is a positive integer;receive a traffic check result sent by the governance center; andsend the service call request to the second service when the traffic check result indicates that the check succeeds.

In some possible implementations, the communications module is further configured to:receive a service call response sent by the second service, where the service call response includes second data obtained by processing the first data by the second service.

The apparatus1040further includes:a generation module1044, configured to generate a service call log based on at least one of the service call request and the service call response.

The communications module1042is further configured to:send the service call log to a data collection center in batches.

In some possible implementations, the apparatus1040further includes:a subscription module1046, configured to subscribe to a change message for a service provider list, to determine, from a changed service provider list, the address of the second device providing the second service.

In some possible implementations, the apparatus1040further includes:the subscription module1046, configured to subscribe to a change message for a service governance rule; anda service governance module1048, configured to run the service governance logic for the first data according to a changed service governance rule.

In some possible implementations, the network interface card is a smart network interface card.

The microservice call apparatus1040according to this embodiment of this application may correspondingly perform the methods described in embodiments of this application, and the foregoing and other operations and/or functions of the modules of the microservice call apparatus1040are separately used to implement corresponding procedures of the methods in the embodiment shown inFIG.2. For brevity, details are not described herein again.

FIG.5is a schematic diagram of a structure of a microservice call apparatus, and the microservice call apparatus1240includes:a communications module1242, configured to receive service call requests sent by a plurality of first services, where each of the plurality of first services is corresponding to one second service, and the second service is used to process first data of a service call request generated by the first service corresponding to the second service.

The communications module1242is further configured to send the service call request to the second service.

The communications module1242is further configured to receive a service call response sent by the second service, where the service call response includes second data obtained by processing the first data by the second service.

The communications module1242is further configured to send the service call response to the first service corresponding to the second service.

In some possible implementations, the apparatus1240further includes:a generation module1244, configured to generate a service call log based on at least one of the service call request and the service call response.

The communications module1242is further configured to send the service call log to a data collection center in batches.

In some possible implementations, the network interface card is a smart network interface card.

The microservice call apparatus1240according to this embodiment of this application may correspondingly perform the methods described in embodiments of this application, and the foregoing and other operations and/or functions of the modules of the microservice call apparatus1240are separately used to implement corresponding procedures of the methods in the embodiment shown inFIG.2. For brevity, details are not described herein again.

An embodiment of this application further provides a device. The device may be a network interface card, and is configured to implement a function of the microservice call apparatus1040in the embodiment shown inFIG.4.

FIG.6is a schematic diagram of a structure of a device. As shown inFIG.6, a device600includes a bus601, a processor602, a communications interface603, and a memory604. The processor602, the memory604, and the communications interface603communicate with each other through the bus601. The bus601may be a peripheral component interconnect (PCI) bus, an extended industry standard architecture (EISA) bus, or the like. Buses may be classified into an address bus, a data bus, a control bus, and the like. For ease of representation, only one bold line is used to represent the bus inFIG.6, but this does not mean that there is only one bus or only one type of bus. The communications interface603is configured to communicate with the outside. For example, the communications interface603is configured to receive a service call request, send a service call request, or the like.

The processor602may be a central processing unit (CPU). The memory604may include a volatile memory, for example, a random access memory (RAM). Alternatively, the memory604may include a non-volatile memory, for example, a read-only memory (ROM), a flash memory, an HDD, or an SSD.

The memory604stores executable code, and the processor602executes the executable code to perform the foregoing microservice call method.

When the embodiment shown inFIG.4is implemented, and the modules of the microservice call apparatus1040described in the embodiment ofFIG.4are implemented by using software, software or program code required for performing functions of the generation module1044, the subscription module1046, and the service governance module1048inFIG.4is stored in the memory604. A function of the communications module1042is implemented by using the communications interface603. The communications interface603receives service call requests separately generated by a plurality of first services deployed on a first device, and transmits the service call requests to the processor602through the bus601. The processor602executes program code that is corresponding to each module and that is stored in the memory604, to perform the microservice call method, to send the service call requests to second services by using the communications interface603based on service governance logic related to first data, to implement microservice calling.

An embodiment of this application further provides another device. The device may be a network interface card, including a common network interface card or a smart network interface card, and is configured to implement a function of the microservice call apparatus1240in the embodiment shown inFIG.5.

FIG.7is a schematic diagram of a structure of a device. As shown inFIG.7, a device700includes a bus701, a processor702, a communications interface703, and a memory704. The processor702, the memory704, and the communications interface703communicate with each other through the bus701.

The memory704stores executable code, and the processor702executes the executable code to perform the foregoing microservice call method.

When the embodiment shown inFIG.5is implemented, and the modules of the microservice call apparatus1240described in the embodiment ofFIG.5are implemented by using software, software or program code required for performing a function of the generation module1244inFIG.5is stored in the memory704. A function of the communications module1242is implemented by using the communications interface703. The communications interface703receives service call requests separately sent by a plurality of first services, and transmits the service call requests to the processor702through the bus701. The processor702executes program code that is corresponding to each module and that is stored in the memory704, to perform the microservice call method.

An embodiment of this application further provides a computer-readable storage medium. The computer-readable storage medium includes instructions, and the instructions instruct a network interface card to perform the foregoing microservice call method applied to the microservice call apparatus1040.

An embodiment of this application further provides a computer-readable storage medium. The computer-readable storage medium includes instructions, and the instructions instruct a network interface card to perform the foregoing microservice call method applied to the microservice call apparatus1240.

An embodiment of this application further provides a computer program product. When the computer program product is executed by a network interface card, the network interface card performs any one of the foregoing microservice call methods. The computer program product may be a software installation package. If any one of the foregoing microservice call methods needs to be used, the computer program product may be downloaded, and the computer program product may be executed on a network interface card.