A microservice calling method, device, equipment and medium

Abstract

The present application provides a microservice calling method, including: a network card receives service calling requests respectively generated by multiple first services deployed on a first device, each of the multiple first services corresponds to a second service, the second service is used to process first data of the service calling request generated by the first service corresponding to the second service, and the network card sends the service calling request to the second service based on the service governance logic related to the first data, thereby solving the problem of multiple agents competing for system resources, resulting in process context switching, and then causing a sharp increase in service delay, and improving application performance.

Description

[0001] This application claims the priority of the Chinese patent application filed with the China Intellectual Property Office on March 12, 2020, with application number 202010168547.8 and application name “A high-performance, low-intrusive microservice architecture method”, the entire contents of which are incorporated by reference in this application. Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a microservice invocation method, apparatus, device, and computer-readable storage medium. Background Art

[0003] When developers use traditional monolithic architecture to develop applications, such as customer relationship management (CRM), enterprise resource planning (ERP) and other large applications, it becomes increasingly difficult for developers to update and repair these large monolithic applications as new requirements continue to increase. Based on this, the industry has proposed a new architecture, namely microservice architecture.

[0004] The microservice architecture aims to decouple solutions by breaking down functionality into discrete services. On the one hand, this makes it easier for developers to update and repair applications. On the other hand, a failure in one service does not affect the entire application, thus improving the robustness of the application.

[0005] Currently, the industry mainly uses service mesh (that is, configuring a separate proxy for each microservice, also known as a side car) to migrate applications to the microservice framework for development. However, this method increases the service call latency sharply and reduces application performance. Summary of the invention

[0006] The present application provides a microservice calling method, which solves the problem of a sharp increase in service calling delay under a traditional microservice framework, which in turn leads to a decrease in application performance. The present application also provides a device, equipment, computer-readable storage medium and computer program product corresponding to the microservice calling method.

[0007] In the first aspect, the present application provides a microservice calling method. The method implements the functions completed by decentralized agents through a network card. Specifically, the network card receives service call requests generated by multiple first services deployed on a first device, wherein each of the multiple first services corresponds to a second service, and the second service is specifically used to process the first data of the service call request generated by the first service corresponding to the second service. Then, the network card sends the service call request to the second service based on the service governance logic related to the first data. On the one hand, the network card is used to replace the agent in the microservice framework, maintaining low intrusion; on the other hand, the network card can centrally process service call requests initiated by different services, avoiding the problem of each agent competing for system resources such as the central processor unit (CPU) to generate process context switching, which in turn leads to increased service call delays and improves application performance.

[0008] In addition, centralized processing of service call requests through the network card avoids the occupation of a large amount of resources caused by competition among different agents, thereby improving resource utilization.

[0009] In some possible implementations, the device for deploying the second service may include multiple devices. To this end, the network card can determine the address of the second device providing the second service according to the service governance logic related to the first data, such as load balancing logic, and then the network card sends a service call request to the second service according to the address of the second device. In this way, the functions of service discovery, load balancing, encryption, identity authentication authorization, and fuse can be decoupled from microservices, maintaining the advantage of low intrusion.

[0010] In some possible implementations, considering security issues, the network card can also perform traffic checks on service call requests to prevent illegal elements from frequently sending service call requests, which makes it difficult for the service provider to provide services normally to the outside world. Specifically, the network card can send a traffic check request to the governance center, and the traffic check request is used to perform traffic checks on N service call requests, where N is a positive integer. The network card then receives the traffic check result sent by the governance center, and when the traffic check result indicates that the check has passed, it executes the step of sending the service call request to the second service. By sending service call requests in batches to the governance center through the network card and performing traffic checks, the additional transmission overhead caused by different agents sending service call requests to the governance center separately can be avoided, reducing the overhead of the network card interacting with the governance center on the data plane.

[0011] In some possible implementations, considering the traceability issue, the network card can also generate a service call log for query when the service is abnormal. Specifically, the network card can receive a service call response sent by the second service, and the service call response includes the second data obtained by the second service processing the first data. Then the network card can generate a service call log based on at least one of the service call request and the service call response, and then the network card sends the service call log to the data collection center in batches. Compared with different agents sending service call logs to the data collection center separately, this method can greatly reduce the overhead of the network card interacting with the data collection center on the data plane.

[0012] In some possible implementations, considering that the device providing the service (i.e., the service provider) may experience abnormal conditions such as downtime, in order to avoid sending a service call request to a failed service provider, the network card may also subscribe to a change message for a service provider list, so that the network card can determine the address of the second device providing the second service from the changed service provider list. This can improve service reliability.

[0013] In some possible implementations, taking into account that the service governance rules may change, the network card can also subscribe to change messages for the service governance rules. In this way, the network card can run the service governance logic on the first data according to the changed service governance rules to perform service governance.

[0014] In some possible implementations, the network card is specifically a smart network card. A smart network card is a network card with programmable capabilities, which can be used to assist the CPU in processing network traffic, etc. As an example, the smart network card can specifically be a network card embedded with a field-programmable gate array (FPGA).

[0015] In the second aspect, the present application provides a microservice calling method. The method implements the functions completed by decentralized agents through a network card. Specifically, the network card receives service call requests sent by multiple first services, each of the multiple first services corresponds to a second service, and the second service is used to process the first data of the service call request generated by the first service corresponding to the second service. Then the network card sends the service call request to the second service, and then the network card receives the service call response sent by the second service, which includes the second data obtained by the second service processing the first data, and finally the network card sends the service call response to the first service corresponding to the second service.

[0016] On the one hand, the network card is used instead of the agent in the microservice framework to maintain low intrusion; on the other hand, the network card can centrally process service call requests initiated by different services, avoiding the problem of each agent competing for system resources CPU and causing process context switching, which in turn leads to increased service call delays, thereby improving application performance.

[0017] In some possible implementations, the network card generates a service call log according to at least one of the service call request and the service call response, and then the network card sends the service call log to the data collection center in batches. Compared with different agents sending service call logs to the data collection center separately, this method can greatly reduce the overhead of the network card interacting with the data collection center on the data plane.

[0018] In some possible implementations, the network card is specifically a smart network card. The smart network card has programmable capabilities. As an example, the smart network card can be a network card embedded with an FPGA.

[0019] In a third aspect, the present application provides a microservice calling device, the device comprising:

[0020] A communication module, configured to receive service call requests respectively generated by a plurality of first services deployed on a first device, each of the plurality of first services respectively corresponding to a second service, the second service being configured to process first data of the service call request generated by the first service corresponding to the second service;

[0021] The communication module is also used to send the service call request to the second service based on the service governance logic related to the first data.

[0022] In some possible implementations, the communication module is specifically used to:

[0023] Determine an address of a second device providing the second service according to a service governance logic related to the first data;

[0024] A service invocation request is sent to the second service according to the address of the second device.

[0025] In some possible implementations, the communication module is further configured to:

[0026] Send a traffic inspection request to the governance center, where the traffic inspection request is used to perform traffic inspection on N service call requests, where N is a positive integer;

[0027] Receiving the flow inspection result sent by the management center;

[0028] When the traffic inspection result indicates that the inspection is passed, the step of sending the service call request to the second service is executed.

[0029] In some possible implementations, the communication module is further configured to:

[0030] receiving a service call response sent by the second service, where the service call response includes second data obtained by the second service processing the first data;

[0031] The device also includes:

[0032] A generating module, configured to generate a service call log according to at least one of the service call request and the service call response;

[0033] The communication module is also used for:

[0034] The service call logs are sent to a data collection center in batches.

[0035] In some possible implementations, the device further includes:

[0036] The subscription module is used to subscribe to the change message of the service provider list to determine the address of the second device providing the second service from the changed service provider list.

[0037] In some possible implementations, the device further includes:

[0038] A subscription module, used to subscribe to change messages for the service governance rules;

[0039] The service governance module is used to run the service governance logic on the first data according to the changed service governance rules.

[0040] In some possible implementations, the network card is a smart network card.

[0041] In a fourth aspect, the present application provides a microservice calling device, the device comprising:

[0042] A communication module, configured to receive service call requests sent by a plurality of first services, each of the plurality of first services corresponding to a second service, the second service being configured to process first data of the service call request generated by the first service corresponding to the second service;

[0043] The communication module is further used to send the service call request to the second service;

[0044] The communication module is further configured to receive a service call response sent by the second service, wherein the service call response includes second data obtained by the second service processing the first data;

[0045] The communication module is further used to send the service call response to the first service corresponding to the second service.

[0046] In some possible implementations, the device further includes:

[0047] A generating module, configured to generate a service call log according to at least one of the service call request and the service call response;

[0048] The communication module is also used to send the service call logs to the data collection center in batches.

[0049] In some possible implementations, the network card is a smart network card.

[0050] In a fifth aspect, the present application provides a network card, comprising a processor and a memory. The processor and the memory communicate with each other. The processor is used to execute instructions stored in the memory, so that the network card executes the microservice calling method in the first aspect or any implementation of the first aspect.

[0051] In a sixth aspect, the present application provides a network card, comprising a processor and a memory. The processor and the memory communicate with each other. The processor is used to execute instructions stored in the memory, so that the network card executes the microservice calling method in the second aspect or any implementation of the second aspect.

[0052] In a seventh aspect, the present application provides a computer-readable storage medium. The computer-readable storage medium includes instructions, and the instructions instruct the network card to execute the microservice calling method described in the first aspect or any implementation of the first aspect.

[0053] In an eighth aspect, the present application provides a computer-readable storage medium. The computer-readable storage medium includes instructions, and the instructions instruct the network card to execute the microservice calling method described in the second aspect or any implementation of the second aspect.

[0054] In a ninth aspect, the present application provides a computer program product comprising instructions, which, when running on a network card, enables the network card to execute the microservice calling method described in the first aspect or any one of the implementations of the first aspect.

[0055] In a tenth aspect, the present application provides a computer program product comprising instructions, which, when running on a network card, enables the network card to execute the microservice calling method described in the second aspect or any one of the implementations of the second aspect.

[0056] Based on the implementations provided in the above aspects, this application can also be further combined to provide more implementations. BRIEF DESCRIPTION OF THE DRAWINGS

[0057] In order to more clearly illustrate the technical method of the embodiments of the present application, the drawings required for use in the embodiments are briefly introduced below.

[0058] Figure 1 A system architecture diagram of a microservice calling method provided in an embodiment of the present application;

[0059] Figure 2 An interactive flow chart of a microservice calling method provided in an embodiment of the present application;

[0060] Figure 3 A processing logic diagram of a microservice calling method provided in an embodiment of the present application;

[0061] Figure 4 A schematic diagram of the structure of a microservice calling device provided in an embodiment of the present application;

[0062] Figure 5 A schematic diagram of the structure of a microservice calling device provided in an embodiment of the present application;

[0063] Figure 6 A schematic diagram of the structure of a device provided in an embodiment of the present application;

[0064] Figure 7 A schematic diagram of the structure of a device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0065] The scheme in the embodiments provided in this application will be described below in conjunction with the drawings in this application.

[0066] The terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances. This is just a way of distinguishing objects with the same attributes when describing the embodiments of this application.

[0067] In order to facilitate understanding of the technical solution of the present application, some technical terms involved in the present application are introduced below.

[0068] A microservice is a small service consisting of a single application. Each microservice has its own process, which can communicate with other microservices through lightweight communication mechanisms, such as application programming interfaces (APIs) based on the hypertext transfer protocol (HTTP).

[0069] Microservice architecture is an architecture that splits applications (especially large applications, such as e-commerce systems) into several microservices. In some examples, microservice architecture can specifically include classic architectures such as Spring Cloud and Dubbo, which are less invasive. Compared with the traditional monolithic architecture that concentrates all functional services in one container, the microservice architecture achieves business decoupling by decomposing functions into discrete services. Each business team maintains the microservices corresponding to their respective businesses, which reduces maintenance complexity and improves maintenance efficiency. Moreover, when a single microservice fails, other microservices can continue to work, which improves system stability.

[0070] In some cases, there can be a calling relationship between multiple microservices of an application. For example, in an e-commerce system, the microservice of the product system can also call the microservice of the evaluation system to display the user's historical evaluation of the product when displaying the product details. The so-called service governance is to handle the relationship between service calls under the distributed service framework. Service governance can be specifically divided into the following levels: service registration and discovery, load balancing, fault handling and recovery (current limiting, fuse, timeout, retry), grayscale release, and service tracking.

[0071] Currently, applications based on microservice architecture mainly implement service governance through service mesh. Service mesh is an infrastructure layer used to handle communication between services (including microservices). One way to implement service mesh is to assign a separate agent to each microservice, which is also called a side car. The agent is responsible for handling communication, monitoring and some security-related work between services, thereby providing functions such as service discovery, load balancing, encryption, identity authentication, authorization and fuse. The microservice itself is no longer responsible for processing the specific logic of business requests, such as balancing based on business requests, etc., and only needs to complete business processing.

[0072] For large applications, a physical machine usually runs many proxy containers, for example, hundreds of proxy containers. The number of these hundreds of proxy processes far exceeds the number of CPU cores of the physical machine. When the CPU becomes a system bottleneck due to high concurrent request pressure, a large number of process context switches will inevitably occur due to multiple processes competing for the CPU, which will lead to a sharp increase in service call delays and reduce application performance.

[0073] To this end, an embodiment of the present application provides a microservice calling method, which uses a network card to replace the proxy of the microservice, and concentrates the functions completed by the scattered proxy on the above-mentioned network card. Specifically, the network card can receive a service call request generated by at least one first service deployed on a device (referred to as the first device in this application). Among them, each of the multiple first services corresponds to a second service. The second service is specifically used to process the first data of the service call request generated by the first service corresponding to the second service. Then the network card can send a service call request to the second service according to the service governance logic related to the above-mentioned first data, thereby realizing the microservice call.

[0074] The above method decouples the service discovery, load balancing, encryption, identity authentication, authorization, and fuse functions from microservices through the network card, maintaining the advantage of low intrusion. In addition, the network card can centrally process service call requests for different services, avoiding the sharp increase in service delay caused by the competition of system resources including CPU by agents of different services, thereby improving application performance.

[0075] In addition, the functions performed by the agents of different services are concentrated on the network card, which reduces the complexity of the application and makes the application easier to operate, maintain and control. Furthermore, centralized processing through the network card can realize batch traffic inspection, thus reducing the overhead of interaction between the data plane and the governance center, and reducing the concurrency pressure of the management plane governance center. Of course, centralized processing through the network card can also realize batch log reporting, reduce the overhead of interaction between the data plane and the data collection center, and reduce the concurrency pressure of the management plane data collection center.

[0076] Figure 1 A possible application scenario of an embodiment of the present application is shown. In this application scenario, device 104 and device 124 are network cards. Among them, device 104 has programmable capabilities, and by programming it, customized processing logic can be implemented, such as implementing processing logic for service call requests. Of course, device 124 may also have programmable capabilities. In actual applications, device 104 may be a smart network interface card (smart NID), and device 124 may be an ordinary network card or a smart network card. Among them, a smart network card is a network card with programmable capabilities, and an ordinary network card is a network card without programmable capabilities.

[0077] Device 102 and device 122 are computing devices, which may be physical machines or virtual machines after virtualization. In actual applications, device 102 and device 122 may be servers or cloud servers. Multiple microservices are deployed on device 102 and device 122. Specifically, the microservices deployed on device 102 include service 11, service 12 ... service 1n, and the microservices deployed on device 104 include service 21, service 22 ... service 2n.

[0078] The application scenario may also include device 142, device 162, and device 182. Similarly, device 142, device 162, and device 182 are computing devices, which may be servers or cloud servers. Among them, a registration center 1420 is deployed on device 142. The registration center 1420 records the mapping relationship between services and service addresses. When a microservice calls other microservices, the service address of the called service can be obtained from the registration center 1420 to make a service call. A governance center 1620 is deployed on device 162, and the governance center 1620 records service governance rules. When a microservice calls other microservices, the service governance rules can be obtained from the governance center 1620, and the service governance logic is run based on the service governance rules. A data collection center 1820 is deployed on device 182, and the data collection center 1820 records the service call log. When a microservice fails, the operation and maintenance personnel can perform troubleshooting and maintenance based on the service call log.

[0079] In this scenario, the microservice on the device 102 is the service caller, and the microservice on the device 122 is the service callee. For the sake of distinction, the device 102 may also be referred to as the first device, and the device 122 may also be referred to as the second device.

[0080] In a specific implementation, multiple microservices (referred to as first services in this application) deployed on device 102 can generate service call requests respectively. Each first service corresponds to a second service respectively. The second service is specifically used to process the first data of the service call request generated by the first service corresponding to the second service. Then the first service sends the service call request respectively. A microservice calling device 1040 is deployed on device 104 connected to device 102. The microservice calling device 1040 is used to receive service call requests generated by multiple first services deployed on device 102, such as service 11, service 12...service 1n, and then send the service call request to the second service based on the service governance logic related to the first data.

[0081] A microservice invocation device 1240 is deployed on the device 124, and the microservice invocation device 1240 receives service invocation requests sent by multiple first services, and then sends a service invocation request to a second service deployed on the device 122. The second service responds to the service invocation request, processes the first data of the service invocation request generated by the first service corresponding to the second service, and obtains the second data. The second service can generate a service invocation response based on the second data, and send the service invocation response to the microservice invocation device 1240. When the microservice invocation device 1240 receives the service invocation response, it sends the service invocation response to the first service, thereby implementing the microservice invocation.

[0082] In actual application, the microservice invocation device 1040 deployed on the device 104 may also send a service provider list change subscription request to the device 142. In this way, when a service provider changes, the registration center 1420 deployed on the device 142 may send a change message for the service provider list to the microservice invocation device 1040 deployed on the device 104. In this way, when the microservice invocation device 1040 on the device 104 determines the address of the second device providing the second service from the service provider list, it may determine the address of the second device providing the second service according to the changed service provider list, thereby avoiding sending a service invocation request to an invalid service provider and improving service reliability.

[0083] Similarly, the microservice invocation device 1040 deployed on the device 104 can also send a service governance rule change subscription request to the device 162. In this way, when the service governance rule changes, the governance center 1620 of the device 162 can send a change message for the service governance rule to the microservice invocation device 1040 deployed on the device 104. In this way, when the microservice invocation device 1040 on the device 104 runs the service governance logic on the first data according to the service governance rule, the service governance logic can be run on the first data according to the changed service governance rule, thereby performing service governance.

[0084] It should also be noted that the above scenario is only an example of the microservice deployed on the device 102 as the service caller and the microservice deployed on the device 122 as the service callee. In some implementations, the microservice deployed on the device 122 can also be used as a service caller. When it is used as a service caller, the microservice calling device 1240 has a structure similar to that of the microservice calling device 1040. In addition, the microservice deployed on the device 102 can also be used as a service callee, which is not limited in the embodiments of the present application.

[0085] To facilitate understanding of the technical solution of the present application, the microservice calling method of an embodiment of the present application will be introduced below from the perspective of interaction between the first service, the microservice calling device 1040, the microservice calling device 1240, the second service, and the registration center 1420, the governance center 1620 and the data collection center 1820.

[0086] See also Figure 2 The flowchart of the microservice calling method shown in FIG. 1 includes:

[0087] S202: The microservice calling device 1040 subscribes to the change message for the service provider list.

[0088] Specifically, the microservice invocation device 1040 deployed on the device 104 may send a service provider list change subscription request to the registration center 1420 on the device 142. The service provider list change subscription request is used to request a subscription to a change message for the service provider list. The service provider list change subscription request includes the identifier of the device 104. The registration center 1420 receives the service provider list change subscription request and may add the identifier of the device 104 to the subscription user list. When the service provider list changes, the registration center 1420 may send a change message for the service provider list to the users in the subscription user list. In this way, the microservice invocation device 1040 deployed on the device 104 may obtain a change message for the service provider list.

[0089] It should be understood that in some embodiments, the microservice invocation method may be executed without executing S202. For example, the microservice invocation device 1040 may obtain a service provider list in advance, and perform subsequent operations according to the pre-acquired service provider list.

[0090] S204: The microservice calling device 1040 subscribes to the change message for the service governance rules.

[0091] Among them, service governance refers to the relationship between service calls in the distributed service framework, including service registration and discovery, load balancing, fault handling and recovery (current limiting, fuse, timeout, retry), grayscale release and service tracking. Based on this, the governance center 1620 can define service governance rules, that is, service governance rules. Service governance rules can include load balancing rules, fault handling and recovery rules, etc.

[0092] In a specific implementation, the microservice calling device 1040 deployed on the device 104 can send a service governance rule change subscription request to the governance center 1620 on the device 162. The service governance rule change subscription request is specifically used to request a change message for the service governance rules. Similarly, the service governance rule change subscription request includes the identifier of the device 104. When the governance center 1620 receives the service governance rule change subscription request, it adds the identifier of the device 104 to the subscription user list. When the service governance rules change, the governance center 1620 can send a change message for the service governance rules to the users in the subscription user list. In this way, the microservice calling device 1040 deployed on the device 104 can obtain a change message for the service governance rules.

[0093] It should be noted that the subscription user list maintained by the governance center 1620 is a subscription user list for service governance rules, and the subscription user list maintained by the registration center 1420 is a subscription user list for service provider addresses. That is, the governance center 1620 and the registration center 1420 maintain different subscription user lists respectively.

[0094] It should be understood that in some embodiments, the microservice invocation method may be executed without executing S204. For example, the microservice invocation device 1040 may obtain service governance rules in advance and perform subsequent operations according to the pre-acquired service governance rules.

[0095] S206: Multiple first services deployed on the device 102 send service call requests respectively.

[0096] Among them, multiple first services (such as Figure 1 Each of the first services in the services 11, 12, ..., 1n shown corresponds to a second service, which is specifically used to process the first data of the service call request generated by the first service corresponding to the second service.

[0097] It should be noted that the first data specifically refers to data that needs to be processed by the second service, and the first data that needs to be processed by each service that initiates a service call request can be the same or different, which can be determined according to actual needs. Similarly, the second service requested by each first service that initiates a service call request can be the same or different, and this embodiment of the application does not limit this.

[0098] S208: The microservice calling device 1040 determines the address of the second device providing the second service according to the service governance logic related to the first data.

[0099] The service call request sent by the first service will pass through the device 104. When the microservice calling device 1040 deployed on the device 104 receives the service call request, it can unload the data of the service call request to obtain the first data. The first data includes at least the header of the data packet. In some cases, the first data may also include the body of the data packet. Then, based on the change message for the service governance rule subscribed by S204, the microservice calling device 1040 runs the service governance logic on the first data with the latest (i.e., the most recently changed) service governance rule to determine the address of the second device providing the second service from the service provider list.

[0100] It should be noted that when running the service governance logic on the first data to determine the address of the second device providing the second service from the service provider list, the microservice calling device 1040 can determine the address of the second device providing the second service from the latest (i.e., after the most recent change) service provider list based on the change message for the service provider list subscribed to by S202.

[0101] It should be understood that when the microservice invocation method is executed without executing S202, the microservice invocation device 1040 can determine the address of the second device providing the second service based on the pre-acquired service provider list. When the microservice invocation method is executed without executing S204, the microservice invocation device 1040 can run the service governance logic on the first data based on the pre-acquired service governance rules.

[0102] Among them, the microservice calling device 1040 runs the service governance logic on the first data according to the service governance rules, that is, performs service governance on the first data according to the service governance rules. For ease of understanding, this application also provides a specific example for illustration. In one example, Figure 3 As shown, in the application scenario of the e-commerce system, a microservice as a service 11 of the commodity system initiates a service call request, and the service call request indicates that the evaluation acquisition service as a service 21 in the evaluation system is used to process the data of commodity A, that is, to obtain the historical evaluation of commodity A. The devices that provide the evaluation acquisition service include device 1 located in the East China region, device 2 located in the North China region, device 3 in the South China region, and device 4 in the Central China region. The traffic load of device 1 and the traffic load of device 2 are higher than the traffic load of device 3 and device 4, among which the load of device traffic 4 is the smallest. Then the microservice calling device 1040 on the smart network card determines the address of device 4 as the address of the device that finally provides the evaluation acquisition service based on the load balancing rule, and sends a service call request to the service at the address.

[0103] In actual application, the microservice calling device 1040 can create a working thread, that is, a worker thread, and implement the operation of running the service governance logic to determine the address of the second device providing the second service from the service provider list.

[0104] S210: The microservice calling device 1040 sends a traffic inspection request to the governance center 1620.

[0105] In a specific implementation, the microservice calling device 1040 can add the service calling request and the address of the corresponding second device to a traffic inspection queue, which is specifically a blocking queue. Then the microservice device 1040 can send a traffic inspection request to the governance center 1620 in batches.

[0106] Specifically, the microservice calling device 1040 can create a check thread, namely, a checker thread. The checker thread can take out all service call requests waiting for traffic check from the traffic check queue (multiple service call requests initiated by multiple services deployed on the device 102), generate a traffic check request, and send the traffic check request to the governance center 1620. In this way, the service call requests are sent to the governance center 1620 in batches.

[0107] S212: The microservice calling device 1040 receives the traffic inspection response returned by the governance center 1620. When the traffic inspection result in the traffic inspection response indicates that the inspection is passed, S214 is executed.

[0108] The governance center 1620 can perform batch traffic inspection on multiple service call requests in the traffic inspection request sent by the microservice call device 1040, for example, by checking the source address, etc. to determine whether the service call request is normal traffic or abnormal traffic generated by an attack by an illegal element, etc. Then, the governance center 1620 can generate a traffic inspection response based on the traffic inspection result, and return the traffic inspection response to the microservice call device 1040.

[0109] It should be noted that after the microservice calling device 1040 receives the traffic check response returned by the governance center 1620, the checker thread can also wake up the worker thread corresponding to the batch of service call requests, and then block the new service call requests waiting in the traffic check queue (that is, the service call requests that have not yet been sent to the governance center 1620).

[0110] When the traffic inspection result in the traffic inspection response received by the microservice invoking device 1040 indicates that the inspection is passed, the microservice invoking device 1040 can perform subsequent operations, such as executing S214. When the traffic inspection result in the traffic inspection response received by the service invoking device 1040 indicates that the inspection is not passed, the microservice invoking device 1040 can end the current microservice invoking process.

[0111] It should be understood that S210 and S212 are only optional methods implemented to improve security. In some embodiments, the microservice calling method may not execute S210 and S212. That is, the microservice calling device 1040 may execute S214 after executing S208.

[0112] S214: The microservice calling device 1040 sends a service calling request to the second service according to the address of the second device.

[0113] After determining the address of the second device providing the second service, the microservice calling device 1040 may set the destination address in the service calling request to the address of the second device providing the second service, namely, the device 122, and then send a service calling request to the second service.

[0114] Among them, S208 and S214 are an implementation method in which the microservice calling device 1040 on the network card sends the service calling request to the second service based on the service governance logic related to the first data. In other possible implementation methods of the embodiment of the present application, the microservice calling device 1040 can also send the service calling request to the second service in other ways.

[0115] It should be noted that when the address of the second device providing the second service determined in S208 is different from the destination address of the service call request in S206, the service call request sent by the microservice call device 1040 in S214 will be different from the service call request sent in S206. The difference mainly lies in that the destination address of the service call request sent in S214 is the address of the second device providing the second service re-determined in S208. Of course, in some cases, the package body of the service call request sent in S214 may also be different from the package body of the service call request sent in S206.

[0116] S216: When the microservice calling device 1240 receives the service calling request, it sends the service calling request to the second service.

[0117] The service call request sent by the microservice calling device 1040 to the second service passes through the device 124. When the microservice calling device 1240 deployed on the device 124 receives the service call request, it sends the service call request to the second service. It should be noted that, considering the network heterogeneity, when the microservice calling device 1240 receives the service call request, it can first uninstall the service call request, then regenerate the service call request based on the uninstalled data, and then send the regenerated service call request to the second service.

[0118] S218: The second service returns a service call response.

[0119] When the second service receives the service call request, it can process the first data in response to the service call request to obtain the second data. For example, the service call request instructs the evaluation acquisition service in the evaluation system to process product A and obtain historical evaluations for product A. The evaluation acquisition service can respond to the service call request and obtain historical evaluations for product A from all historical evaluations.

[0120] The second service may generate a service call response according to the second data, the service call response carrying the second data, and then the second service returns the service call response.

[0121] S220: When the microservice calling device 1240 receives the service calling response, it sends the service calling response to the microservice calling device 1040.

[0122] The service call response returned by the second service passes through the device 124. When the microservice calling device 1240 deployed on the device 124 receives the service call response, it sends the service call response to the microservice calling device 1040. It should be noted that, similar to the service call request, the microservice calling device 1240 can also first uninstall the service call response when receiving the service call response, and then regenerate the service call response based on the uninstalled data, and send the regenerated service call response to the microservice calling device 1040 so that the microservice calling device 1040 can recognize the service call response.

[0123] S222: The microservice calling device 1040 sends a service calling response to the first service corresponding to the second service.

[0124] Specifically, when the microservice calling device 1040 receives the service calling response, it can uninstall the service calling response, then regenerate the service calling response based on the uninstalled data, and send the regenerated service calling response to the first service.

[0125] In this way, the first service implements the call to the second service. It should be noted that the service governance work is completed in the device 104, without intrusion into the business logic. For example, when the second service is released in grayscale, the calling logic of the first service and the implementation logic of the second service do not need to be modified at all, and the grayscale release processing logic can be completed in the device 104.

[0126] S224: The microservice calling device 1040 sends a service calling log to the data collection center 1820.

[0127] In some possible implementations, the microservice invocation device 1040 deployed on the device 104 may also generate a service invocation log according to at least one of the received service invocation request and the received service invocation response, and then send the service invocation log in batches to the data collection center 1820. The microservice invocation device 1040 may also set a log upload cycle, so that the microservice invocation device 1040 may send the service invocation log in batches to the data collection center 1820 according to the preset log upload cycle.

[0128] S226: The microservice calling device 1240 sends the service calling log to the data collection center 1820.

[0129] In some possible implementations, the microservice calling device 1240 deployed on the device 124 can also generate a service call log based on at least one of the received service call request and service call response, and then send the service call log to the data collection center 1820 in batches according to a preset period.

[0130] The microservice calling device 1040 and the microservice calling device 1240 upload the service calling logs in batches, which can reduce the overhead of the device 104 interacting with the data collection center 1820 on the data plane, and reduce the overhead of the device 124 interacting with the data collection center 1820 on the data plane, thereby saving costs.

[0131] Among them, the microservice calling device 1040 generates a service calling log according to the received service calling request and service calling response, and the microservice calling device 1240 generates a service calling log according to the received service calling request and service calling response, so that the data collection center 1820 can obtain complete log tracking data, including the time when the first service initiates the service calling request, the time when the second service receives the service calling request, the time when the second service completes the processing, and the time when the first service receives the service calling response. When some microservices fail, troubleshooting and fault maintenance can be performed based on the above complete log tracking data.

[0132] It should be understood that S224 and S226 are merely an optional implementation provided by the embodiment of the present application. In some embodiments, the microservice calling method may be executed without executing S2224 and S2226.

[0133] Figure 2 The steps marked with dotted lines or dotted boxes are optional steps provided in the embodiments of the present application. In some possible implementations, the above steps may not be performed, or may be implemented in other ways. The embodiments of the present application are not limited to this.

[0134] Based on the above description, the microservice calling method provided in the embodiment of the present application uses a network card to replace the agent in the service grid, and the network card centrally processes the service call requests initiated by different services deployed on a device to complete the service governance work and avoid intrusion into the business logic. In addition, the network card can centrally process the service call requests initiated by different services, avoiding the problem of a sharp increase in latency caused by different services competing for system resources including the CPU, reducing the resource occupancy rate of the application, improving the application response efficiency, and thus improving the application performance.

[0135] Combined with the above Figures 1 to 3 , describes in detail the microservice calling method provided in the embodiment of the present application. The following will describe the microservice calling device and corresponding equipment provided in the embodiment of the present application in conjunction with the accompanying drawings.

[0136] See also Figure 4 The structural diagram of the microservice calling device shown in FIG. 1040 includes:

[0137] A communication module 1042 is used to receive service call requests respectively generated by multiple first services deployed on the first device, each of the multiple first services corresponds to a second service, and the second service is used to process first data of the service call request generated by the first service corresponding to the second service;

[0138] The communication module 1042 is further used to send the service call request to the second service based on the service governance logic related to the first data.

[0139] In some possible implementations, the communication module 1042 is specifically used to:

[0140] Determine an address of a second device providing the second service according to a service governance logic related to the first data;

[0141] Send a service call request to the second service according to the address of the second device.

[0142] In some possible implementations, the communication module 1042 is further configured to:

[0143] Send a traffic inspection request to the governance center, where the traffic inspection request is used to perform traffic inspection on N service call requests, where N is a positive integer;

[0144] Receiving the flow inspection result sent by the management center;

[0145] When the traffic inspection result indicates that the inspection is passed, the step of sending the service call request to the second service is executed.

[0146] In some possible implementations, the communication module is further configured to:

[0147] receiving a service call response sent by the second service, where the service call response includes second data obtained by the second service processing the first data;

[0148] The device 1040 further includes:

[0149] A generating module 1044, configured to generate a service call log according to at least one of the service call request and the service call response;

[0150] The communication module 1042 is also used for:

[0151] The service call logs are sent to a data collection center in batches.

[0152] In some possible implementations, the device 1040 further includes:

[0153] The subscription module 1046 is configured to subscribe to a change message for the service provider list, so as to determine the address of the second device providing the second service from the changed service provider list.

[0154] In some possible implementations, the device 1040 further includes:

[0155] Subscription module 1046, used to subscribe to change messages for the service governance rules;

[0156] The service governance module 1048 is used to run the service governance logic on the first data according to the changed service governance rules.

[0157] In some possible implementations, the network card is a smart network card.

[0158] The microservice invocation device 1040 according to the embodiment of the present application may correspond to the method described in the embodiment of the present application, and the above and other operations and / or functions of each module of the microservice invocation device 1040 are respectively to implement Figure 2 For the sake of brevity, the corresponding processes of each method in the illustrated embodiment are not described in detail here.

[0159] Next, see Figure 5 The microservice calling device 1240 shown in the structure diagram includes:

[0160] The communication module 1242 is used to receive service call requests sent by multiple first services, each of the multiple first services corresponds to a second service, and the second service is used to process the first data of the service call request generated by the first service corresponding to the second service;

[0161] The communication module 1242 is further configured to send the service call request to the second service;

[0162] The communication module 1242 is further configured to receive a service call response sent by the second service, wherein the service call response includes second data obtained by the second service processing the first data;

[0163] The communication module 1242 is further configured to send the service call response to the first service corresponding to the second service.

[0164] In some possible implementations, the device 1240 further includes:

[0165] A generating module 1244, configured to generate a service call log according to at least one of the service call request and the service call response;

[0166] The communication module 1242 is also used to send the service call logs to the data collection center in batches.

[0167] In some possible implementations, the network card is a smart network card.

[0168] The microservice invocation device 1240 according to the embodiment of the present application may correspond to executing the method described in the embodiment of the present application, and the above and other operations and / or functions of each module of the microservice invocation device 1240 are respectively to implement Figure 2 For the sake of brevity, the corresponding processes of each method in the illustrated embodiment are not described in detail here.

[0169] The present application also provides a device. The device may be a network card, which is specifically used to implement the following Figure 4 The functions of the microservice calling device 1040 in the illustrated embodiment.

[0170] Figure 6 A schematic diagram of the structure of a device is provided, such as Figure 6As shown, device 600 includes bus 601, processor 602, communication interface 603 and memory 604. Processor 602, memory 604 and communication interface 603 communicate through bus 601. Bus 601 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 6 The communication interface 603 is used to communicate with the outside, for example, to receive a service call request, to send a service call request, and so on.

[0171] The processor 602 may be a central processing unit (CPU). The memory 604 may include a volatile memory, such as a random access memory (RAM). The memory 604 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a HDD or a SSD.

[0172] The memory 604 stores executable code, and the processor 602 executes the executable code to execute the aforementioned microservice calling method.

[0173] Specifically, in implementing Figure 4 In the case of the embodiment shown, and Figure 4 When each module of the microservice calling device 1040 described in the embodiment is implemented by software, the execution Figure 4 The software or program code required for the functions of the generation module 1044, the subscription module 1046, and the service governance module 1048 in the first device are stored in the memory 604. The function of the communication module 1042 is implemented through the communication interface 603. The communication interface 603 receives the service call requests generated by the multiple first services deployed on the first device, and transmits them to the processor 602 through the bus 601. The processor 602 executes the program code corresponding to each module stored in the memory 604, and executes the microservice call method to send the service call request to the second service through the communication interface 603 based on the service governance logic related to the first data, thereby realizing the microservice call.

[0174] The present application embodiment also provides another device. The device may be a network card, including a common network card or a smart network card, specifically used to implement the following Figure 5 The functions of the microservice calling device 1240 in the illustrated embodiment.

[0175] Figure 7 A schematic diagram of the structure of a device is provided, such as Figure 7 As shown, the device 700 includes a bus 701, a processor 702, a communication interface 703, and a memory 704. The processor 702, the memory 704, and the communication interface 703 communicate with each other via the bus 701.

[0176] The memory 704 stores executable code, and the processor 702 executes the executable code to execute the aforementioned microservice calling method.

[0177] Specifically, in implementing Figure 5 In the case of the embodiment shown, and Figure 5 When each module of the microservice calling device 1240 described in the embodiment is implemented by software, the execution Figure 5 The software or program code required for the function of the generation module 1244 is stored in the memory 704. The function of the communication module 1242 is implemented through the communication interface 703. The communication interface 703 receives the service call requests sent by the multiple first services respectively, and transmits them to the processor 702 through the bus 701. The processor 702 executes the program code corresponding to each module stored in the memory 704 and executes the microservice call method.

[0178] The embodiment of the present application further provides a computer-readable storage medium, which includes instructions, and the instructions instruct the network card to execute the microservice calling method applied to the microservice calling device 1040.

[0179] The embodiment of the present application further provides a computer-readable storage medium, which includes instructions, and the instructions instruct the network card to execute the microservice calling method applied to the microservice calling device 1240.

[0180] The embodiment of the present application also provides a computer program product, and when the computer program product is executed by the network card, the network card executes any of the aforementioned microservice calling methods. The computer program product can be a software installation package, and when any of the aforementioned microservice calling methods is needed, the computer program product can be downloaded and executed on the network card.

Claims

1. A microservice calling method, characterized in that: The method comprises: The network card receives service call requests respectively generated by a plurality of first services deployed on the first device, each of the plurality of first services respectively corresponds to a second service, and the second service is used to process first data of the service call request generated by the first service corresponding to the second service; The network card determines, according to the service governance logic related to the first data, an address of a second device that provides the second service, where the second service is a service corresponding to each of the multiple first services; The network card sends the service call request to the second service according to the address of the second device. The first data in the service call request is unloaded by the network card of the second device, and the network card of the second device regenerates the service call request processed by the second service.

2. The method according to claim 1, characterized in that The method further comprises: The network card sends a traffic inspection request to the governance center, where the traffic inspection request is used to perform traffic inspection on N service call requests, where N is a positive integer; The network card receives the flow inspection result sent by the management center; When the traffic inspection result indicates that the inspection is passed, a step of centrally sending the service call request to a second service corresponding to each of the multiple first services is performed.

3. The method according to claim 1, characterized in that The method further comprises: The network card receives a service call response sent by the second service, where the service call response includes second data obtained by the second service processing the first data; The network card generates a service call log according to at least one of the service call request and the service call response; The network card sends the service call logs to the data collection center in batches.

4. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The network card subscribes to a change message for a service provider list to determine an address of a second device providing the second service from the changed service provider list.

5. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The network card subscribes to change messages for service governance rules; The network card runs service management logic on the first data according to the changed service management rules.

6. The method according to any one of claims 1 to 3, characterized in that: The network card is a smart network card.

7. A microservice calling method, characterized in that: The method comprises: The network card receives service call requests sent by multiple first services, each of the multiple first services corresponds to a second service, and the second service is used to process first data of the service call request generated by the first service corresponding to the second service; The network card determines, according to the service governance logic related to the first data, an address of a second device providing the second service; The network card sends the service call request to the second service according to the address of the second device, the first data in the service call request is unloaded by the network card of the second device, and the network card of the second device regenerates the service call request processed by the second service; The network card receives a service call response sent by the second service, where the service call response includes second data obtained by the second service processing the first data; The network card sends the service call response to the first service corresponding to the second service.

8. The method according to claim 7, characterized in that The method further comprises: The network card generates a service call log according to at least one of the service call request and the service call response; The network card sends the service call logs to the data collection center in batches.

9. The method according to claim 7 or 8, characterized in that: The network card is a smart network card.

10. A microservice calling device, characterized in that: The microservice calling device is deployed on a network card, and the device includes: A communication module, configured to receive service call requests respectively generated by a plurality of first services deployed on a first device, each of the plurality of first services respectively corresponding to a second service, the second service being configured to process first data of the service call request generated by the first service corresponding to the second service; The communication module is also used Determine, according to the service governance logic related to the first data, an address of a second device that provides the second service, where the second service is a service corresponding to each of the multiple first services; The service call request is sent to the second service according to the address set of the second device, the first data in the service call request is unloaded by the network card of the second device, and the network card of the second device regenerates the service call request processed by the second service.

11. The device according to claim 10, characterized in that The communication module is also used for: Send a traffic inspection request to the governance center, where the traffic inspection request is used to perform traffic inspection on N service call requests, where N is a positive integer; Receiving the flow inspection result sent by the management center; When the traffic inspection result indicates that the inspection is passed, a step of centrally sending the service call request to a second service corresponding to each of the multiple first services is performed.

12. The device according to claim 10, characterized in that The communication module is also used for: receiving a service call response sent by the second service, where the service call response includes second data obtained by the second service processing the first data; The device also includes: A generating module, configured to generate a service call log according to at least one of the service call request and the service call response; The communication module is also used for: The service call logs are sent to a data collection center in batches.

13. The device according to any one of claims 10 to 12, characterized in that The device also includes: The subscription module is used to subscribe to the change message of the service provider list to determine the address of the second device providing the second service from the changed service provider list.

14. The device according to any one of claims 10 to 12, characterized in that The device also includes: Subscription module, used to subscribe to change messages for service governance rules; The service governance module is used to run the service governance logic on the first data according to the changed service governance rules.

15. The device according to any one of claims 10 to 12, characterized in that The network card is a smart network card.

16. A microservice calling device, characterized in that: The microservice calling device is deployed on a network card, and the device includes: A communication module, configured to receive service call requests sent by a plurality of first services, each of the plurality of first services corresponding to a second service, the second service being configured to process first data of the service call request generated by the first service corresponding to the second service; The communication module is further used to determine the address of the second device providing the second service according to the service governance logic related to the first data; send the service call request to the second service centrally according to the address of the second device, the first data in the service call request is unloaded by the network card of the second device, and the network card of the second device regenerates the service call request processed by the second service; The communication module is further configured to receive a service call response sent by the second service, wherein the service call response includes second data obtained by the second service processing the first data; The communication module is further used to send the service call response to the first service corresponding to the second service.

17. The device according to claim 16, characterized in that The device also includes: A generating module, configured to generate a service call log according to at least one of the service call request and the service call response; The communication module is also used to send the service call logs to the data collection center in batches.

18. The device according to claim 16 or 17, characterized in that The network card is a smart network card.

19. A network card, characterized in that: The network card includes a processor and a memory; The processor is used to execute instructions stored in the memory, so that the network card executes the microservice calling method according to any one of claims 1 to 6.

20. A network card, characterized in that: The network card includes a processor and a memory; The processor is used to execute instructions stored in the memory so that the network card executes the microservice calling method according to any one of claims 7 to 9.

21. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes instructions, and the instructions instruct the network card to execute the microservice calling method according to any one of claims 1 to 6.

22. A computer-readable storage medium, characterized in that: The computer-readable storage medium includes instructions, and the instructions instruct the network card to execute the microservice calling method according to any one of claims 7 to 9.

Images