CN113395310A - 一种微服务调用方法、装置、设备及介质 - Google Patents

Abstract

本申请提供了一种微服务调用方法，包括：网卡接收第一设备上部署的多个第一服务分别生成的服务调用请求，多个第一服务中的每个第一服务分别对应一个第二服务，第二服务用于处理第二服务对应的第一服务所生成的服务调用请求的第一数据，网卡基于所述第一数据相关的服务治理逻辑，向所述第二服务发送所述服务调用请求，如此解决了多个代理竞争系统资源导致进程上下文切换，进而导致服务延时急剧增加的问题，提高了应用性能。

Description

一种微服务调用方法、装置、设备及介质

本申请要求于2020年03月12日提交中国知识产权局、申请号为202010168547.8、申请名称为“一种高性能、低侵入的微服务架构方法”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

本申请涉及计算机技术领域，尤其涉及一种微服务调用方法、装置、设备以及计算机可读存储介质。

背景技术

开发者使用传统的整体式架构(monolithic architecture)开发应用，如客户关系管理系统(customer relationship management，CRM)、企业资源计划系统(enterpriseresource planning，ERP)等大型应用时，随着新需求的不断增加，开发者更新和修复这些大型整体式应用变得越来越困难。基于此，业界提出了一种新的架构，即微服务架构(microservice architecture)。

微服务架构旨在通过将功能分解到各个离散的服务中，从而实现对解决方案的解耦，一方面可以使得开发者易于更新和修复应用，另一方面一个服务发生故障并不会影响整个应用，提高了应用的健壮性。

目前，业界主要采用服务网格(即为每个微服务配置一个单独的代理，也称作边车side car)将应用迁移至微服务框架下进行开发。然而这种方法使得服务调用延时急剧增加，降低了应用性能。

发明内容

本申请提供了一种微服务调用方法，解决了传统微服务框架下服务调用延时急剧增加，进而导致应用性能降低的问题。本申请还提供了该微服务调用方法对应的装置、设备、计算机可读存储介质以及计算机程序产品。

第一方面，本申请提供了一种微服务调用方法。该方法将分散的代理完成的功能通过网卡实现。具体地，网卡接收第一设备上部署的多个第一服务分别生成的服务调用请求，其中，多个第一服务中的每个第一服务分别对应一个第二服务，第二服务具体用于处理该第二服务对应的第一服务所生成的服务调用请求的第一数据。然后，网卡基于所述第一数据相关的服务治理逻辑，向所述第二服务发送所述服务调用请求。一方面，采用网卡代替微服务框架中的代理，保持了低侵入性；另一方面，网卡能够对不同服务发起的服务调用请求进行集中处理，避免了各个代理竞争系统资源如中央处理器(central processor unit，CPU)产生进程上下文切换，进而导致服务调用延时增加的问题，提高了应用性能。

此外，通过网卡对服务调用请求进行集中处理避免了不同代理竞争导致的大量资源被占用，提高了资源利用率。

在一些可能的实现方式中，部署第二服务的设备可以包括多个设备，为此，网卡可以根据第一数据相关的服务治理逻辑，例如负载均衡逻辑，确定提供第二服务的第二设备的地址，然后网卡根据该第二设备的地址向第二服务发送服务调用请求。由此可以实现将服务发现、负载均衡、加密、身份鉴定授权以及熔断等功能从微服务中解耦，保持低侵入性的优点。

在一些可能的实现方式中，考虑到安全性问题，网卡还可以针对服务调用请求进行流量检查，避免非法分子频繁发送服务调用请求，导致服务提供方难以正常对外提供服务。具体地，网卡可以向治理中心发送流量检查请求，该流量检查请求用于针对N个服务调用请求进行流量检查，其中，N为正整数，然后网卡接收所述治理中心发送的流量检查结果，当所述流量检查结果表征检查通过时，执行向所述第二服务发送所述服务调用请求的步骤。通过网卡向治理中心批量发送服务调用请求，进行流量检查，可以避免不同代理分别向治理中心发送服务调用请求所导致的额外传输开销，降低了网卡在数据面与治理中心交互的开销。

在一些可能的实现方式中，考虑到可追溯性问题，网卡还可以生成服务调用日志，以供服务异常时查询使用。具体地，网卡可以接收所述第二服务发送的服务调用响应，该服务调用响应包括所述第二服务对所述第一数据处理所得的第二数据，然后网卡可以根据所述服务调用请求和所述服务调用响应中的至少一个生成服务调用日志，接着网卡以批量形式向数据采集中心发送所述服务调用日志。与不同代理分别向数据采集中心发送服务调用日志相比，该方法能够大幅降低网卡在数据面与数据采集中心交互的开销。

在一些可能的实现方式中，考虑到提供服务的设备(即服务提供者)可能出现宕机等异常情况，为了避免向失效的服务提供者发送服务调用请求，网卡还可以订阅针对服务提供者列表的变更消息，如此，网卡可以从变更后的服务提供者列表中确定提供所述第二服务的第二设备的地址。由此可以提高服务可靠性。

在一些可能的实现方式中，考虑到服务治理规则可能发生变更，网卡还可以订阅针对服务治理规则的变更消息，如此，网卡可以根据变更后的服务治理规则对第一数据运行服务治理逻辑，进行服务治理。

在一些可能的实现方式中，所述网卡具体为智能网卡。智能网卡是具有可编程的能力的网卡，可以用于协助CPU处理网络流量等等。作为一个示例，智能网卡具体可以是嵌入现场可编程门阵列(field-programmable gate array，FPGA)的网卡。

第二方面，本申请提供了一种微服务调用方法。该方法将分散的代理完成的功能通过网卡实现。具体地，网卡接收多个第一服务发送的服务调用请求，所述多个第一服务中的每个第一服务分别对应一个第二服务，所述第二服务用于处理所述第二服务对应的第一服务所生成的服务调用请求的第一数据。然后网卡向所述第二服务发送所述服务调用请求，接着网卡接收所述第二服务发送的服务调用响应，该服务调用响应包括所述第二服务对所述第一数据处理所得的第二数据，最后网卡向所述第二服务对应的所述第一服务发送所述服务调用响应。

一方面，采用网卡代替微服务框架中的代理，保持了低侵入性；另一方面，网卡能够对不同服务发起的服务调用请求进行集中处理，避免了各个代理竞争系统资源CPU产生进程上下文切换，进而导致服务调用延时增加的问题，提高了应用性能。

在一些可能的实现方式中，网卡根据所述服务调用请求和所述服务调用响应中的至少一个生成服务调用日志，然后网卡以批量形式向数据采集中心发送所述服务调用日志。与不同代理分别向数据采集中心发送服务调用日志相比，该方法能够大幅降低网卡在数据面与数据采集中心交互的开销。

在一些可能的实现方式中，所述网卡具体为智能网卡。该智能网卡具有可编程能力。作为一个示例，智能网卡可以是嵌入FPGA的网卡。

第三方面，本申请提供了一种微服务调用装置，所述装置包括：

通信模块，用于接收第一设备上部署的多个第一服务分别生成的服务调用请求，所述多个第一服务中的每个第一服务分别对应一个第二服务，所述第二服务用于处理所述第二服务对应的第一服务所生成的服务调用请求的第一数据；

所述通信模块，还用于基于所述第一数据相关的服务治理逻辑，向所述第二服务发送所述服务调用请求。

在一些可能的实现方式中，所述通信模块具体用于：

根据所述第一数据相关的服务治理逻辑确定提供所述第二服务的第二设备的地址；

根据所述第二设备的地址向所述第二服务发送服务调用请求。

在一些可能的实现方式中，所述通信模块还用于：

向治理中心发送流量检查请求，所述流量检查请求用于针对N个服务调用请求进行流量检查，所述N为正整数；

接收所述治理中心发送的流量检查结果；

当所述流量检查结果表征检查通过时，执行向所述第二服务发送所述服务调用请求的步骤。

在一些可能的实现方式中，所述通信模块还用于：

接收所述第二服务发送的服务调用响应，所述服务调用响应包括所述第二服务对所述第一数据处理所得的第二数据；

所述装置还包括：

生成模块，用于根据所述服务调用请求和所述服务调用响应中的至少一个生成服务调用日志；

所述通信模块还用于：

以批量形式向数据采集中心发送所述服务调用日志。

在一些可能的实现方式中，所述装置还包括：

订阅模块，用于订阅针对服务提供者列表的变更消息，以从变更后的服务提供者列表中确定提供所述第二服务的第二设备的地址。

在一些可能的实现方式中，所述装置还包括：

订阅模块，用于订阅针对所述服务治理规则的变更消息；

服务治理模块，用于根据变更后的服务治理规则对所述第一数据运行服务治理逻辑。

在一些可能的实现方式中，所述网卡为智能网卡。

第四方面，本申请提供了一种微服务调用装置，所述装置包括：

通信模块，用于接收多个第一服务发送的服务调用请求，所述多个第一服务中的每个第一服务分别对应一个第二服务，所述第二服务用于处理所述第二服务对应的第一服务所生成的服务调用请求的第一数据；

所述通信模块，还用于向所述第二服务发送所述服务调用请求；

所述通信模块，还用于接收所述第二服务发送的服务调用响应，所述服务调用响应包括所述第二服务对所述第一数据处理所得的第二数据；

所述通信模块，还用于向所述第二服务对应的所述第一服务发送所述服务调用响应。

在一些可能的实现方式中，所述装置还包括：

生成模块，用于根据所述服务调用请求和所述服务调用响应中的至少一个生成服务调用日志；

所述通信模块，还用于以批量形式向数据采集中心发送所述服务调用日志。

在一些可能的实现方式中，所述网卡为智能网卡。

第五方面，本申请提供一种网卡，所述网卡包括处理器和存储器。所述处理器、所述存储器进行相互的通信。所述处理器用于执行所述存储器中存储的指令，以使得网卡执行如第一方面或第一方面的任一种实现方式中的微服务调用方法。

第六方面，本申请提供一种网卡，所述网卡包括处理器和存储器。所述处理器、所述存储器进行相互的通信。所述处理器用于执行所述存储器中存储的指令，以使得网卡执行如第二方面或第二方面的任一种实现方式中的微服务调用方法。

第七方面，本申请提供一种计算机可读存储介质。所述计算机可读存储介质包括指令，所述指令指示网卡执行上述第一方面或第一方面的任一种实现方式所述的微服务调用方法。

第八方面，本申请提供一种计算机可读存储介质。所述计算机可读存储介质包括指令，所述指令指示网卡执行上述第二方面或第二方面的任一种实现方式所述的微服务调用方法。

第九方面，本申请提供了一种包含指令的计算机程序产品，当其在网卡上运行时，使得网卡执行上述第一方面或第一方面的任一种实现方式所述的微服务调用方法。

第十方面，本申请提供了一种包含指令的计算机程序产品，当其在网卡上运行时，使得网卡执行上述第二方面或第二方面的任一种实现方式所述的微服务调用方法。

本申请在上述各方面提供的实现方式的基础上，还可以进行进一步组合以提供更多实现方式。

附图说明

为了更清楚地说明本申请实施例的技术方法，下面将对实施例中所需使用的附图作以简单地介绍。

图1为本申请实施例提供的一种微服务调用方法的系统架构图；

图2为本申请实施例提供的一种微服务调用方法的交互流程图；

图3为本申请实施例提供的一种微服务调用方法的处理逻辑图；

图4为本申请实施例提供的一种微服务调用装置的结构示意图；

图5为本申请实施例提供的一种微服务调用装置的结构示意图；

图6为本申请实施例提供的一种设备的结构示意图；

图7为本申请实施例提供的一种设备的结构示意图。

具体实施方式

下面将结合本申请中的附图，对本申请提供的实施例中的方案进行描述。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，这仅仅是描述本申请的实施例中对相同属性的对象在描述时所采用的区分方式。

为了便于理解本申请的技术方案，下面对本申请涉及的一些技术术语进行介绍。

微服务(microservice)是指由单一应用程序构成的小服务。每个微服务拥有自己的进程，其可以通过轻量级通信机制，例如基于超文本传输协议(hypertext transferprotocol，HTTP)的应用程序编程接口(application programming interface，API)，实现与其他微服务的通信。

微服务架构(microservice architecture)是一种将应用(尤其是大型应用，如电商系统)拆分成若干个微服务的架构。在一些示例中，微服务架构具体可以包括具有较低侵入性的Spring Cloud、Dubbo等经典架构。与传统单体架构将所有功能服务集中在一个容器相比，微服务架构通过将功能分解到各个离散的服务中，实现了业务解耦。每个业务团队分别维护各自业务对应的微服务，降低了维护复杂度，提高了维护效率。而且单个微服务出现故障时，其他微服务仍可继续工作，提高了系统稳定性。

在一些情况下，应用的多个微服务之间还可以存在调用关系。例如，在电商系统中，商品系统的微服务还可以调用评价系统的微服务，以在显示商品详情时显示用户对该商品的历史评价。所谓服务治理即是在分布式服务框架下处理服务调用之间的关系。服务治理具体可以分为以下层面：服务注册与发现、负载均衡、故障处理与恢复(限流、熔断、超时、重试)、灰度发布以及服务追踪等。

当前，基于微服务架构的应用主要通过服务网格(service mesh)实现服务治理。服务网格是一个用于处理服务(包括微服务)间通信的基础设施层。服务网格的一种实现方式是为每个微服务分配一个单独的代理，该代理也被称之为边车(side car)。其中，代理用于负责处理服务间的通信、监控以及一些与安全的工作，从而实现提供诸如服务发现、负载均衡、加密、身份鉴定、授权以及熔断等功能。微服务自身不再负责处理业务请求的具体逻辑，例如基于业务请求进行负责均衡等等，仅需完成业务处理。

针对大型应用，一台物理机上通常会运行较多代理的容器，例如运行多达上百个代理的容器。而这上百个代理的进程数远远超过物理机的处理器(central processorunit，CPU)核数，当因并发请求压力大而使CPU成为系统瓶颈时，必然由于多进程争抢CPU而产生大量的进程上下文切换，如此导致服务调用延时急剧增加，降低了应用性能。

为此，本申请实施例提供了一种微服务调用方法，该方法采用网卡代替微服务的代理，将分散的代理完成的功能集中到上述网卡完成。具体地，网卡可以接收一设备(本申请称之为第一设备)上部署的至少一个第一服务生成的服务调用请求。其中，多个第一服务中的每个第一服务分别对应一个第二服务。该第二服务具体用于处理第二服务对应的第一服务所生成的服务调用请求的第一数据。然后网卡可以根据上述第一数据相关的服务治理逻辑向第二服务发送服务调用请求，从而实现微服务调用。

上述方法通过网卡将服务发现、负载均衡、加密、身份鉴定、授权以及熔断等功能从微服务中解耦，保持了低侵入性的优点。并且，网卡能够对不同服务的服务调用请求进行集中处理，避免了不同服务的代理竞争CPU在内的系统资源导致服务延时急剧增加，提高了应用性能。

此外，不同服务的代理所完成的功能集中到网卡上，降低了应用的复杂性，使得应用更加易于运维管控。进一步地，通过网卡进行集中化处理，可以实现批量地流量检查，如此，降低了数据面与治理中心交互的开销，并且降低管理面治理中心的并发压力。当然，通过网卡进行集中化处理，也可以实现批量上报日志，降低数据面与数据采集中心交互的开销，并且降低管理面数据采集中心并发压力。

图1示出了本申请实施例的一种可能的应用场景。在该应用场景中，设备104和设备124为网卡。其中，设备104具有可编程的能力，通过对其进行编程，可以实现定制化的处理逻辑，如实现对服务调用请求的处理逻辑。当然，设备124也可以具有可编程的能力。在实际应用时，设备104可以是智能网卡(smart network interface card，smart NID)，设备124可以是普通网卡或智能网卡。其中，智能网卡是具有可编程的能力的网卡，普通网卡是不具有可编程的能力的网卡。

设备102和设备122为计算设备，该计算设备可以是物理机，也可以是经过虚拟化后的虚拟机。在实际应用时，设备102和设备122可以是服务器或者云服务器。设备102和设备122上部署有多个微服务。具体地，设备102上部署的微服务包括服务11、服务12…服务1n，设备104上部署的微服务包括服务21、服务22…服务2n。

该应用场景中还可以包括设备142、设备162和设备182。类似地，设备142、设备162和设备182为计算设备，该计算设备可以是服务器或者云服务器。其中，设备142上部署有注册中心1420。注册中心1420记录有服务和服务地址的映射关系。当某一微服务调用其他微服务时，可以从注册中心1420获取被调用服务的服务地址，进行服务调用。设备162上部署有治理中心1620，治理中心1620记录有服务治理规则。当某一微服务调用其他微服务时，可以从治理中心1620获取服务治理规则，基于该服务治理规则运行服务治理逻辑。设备182上部署有数据采集中心1820，数据采集中心1820记录有服务调用日志，当微服务发生故障时，运维人员可以基于服务调用日志进行故障排除和维护。

在该场景中，设备102上的微服务为服务调用方，设备122上的微服务为服务被调用方。为了便于区分，上述设备102也可以称作第一设备，上述设备122也可以称作第二设备。

在具体实现时，设备102上部署的多个微服务(本申请称之为第一服务)可以分别生成服务调用请求。每个第一服务分别对应于一个第二服务。该第二服务具体用于处理第二服务对应的第一服务生成的服务调用请求的第一数据。然后第一服务分别发送服务调用请求。与设备102连接的设备104上部署有微服务调用装置1040。该微服务调用装置1040用于接收设备102上部署的多个第一服务如服务11、服务12…服务1n分别生成的服务调用请求，然后基于所述第一数据相关的服务治理逻辑，向所述第二服务发送所述服务调用请求。

设备124上部署有微服务调用装置1240，该微服务调用装置1240接收多个第一服务发送的服务调用请求，然后向设备122上部署的第二服务发送服务调用请求。第二服务响应于服务调用请求，处理所述第二服务对应的第一服务所生成的服务调用请求的第一数据，得到第二数据。第二服务可以基于该第二数据生成服务调用响应，并向微服务调用装置1240发送服务调用响应。微服务调用装置1240接收到该服务调用响应时，向第一服务发送服务调用响应，从而实现微服务调用。

在实际应用时，设备104上部署的微服务调用装置1040还可以向设备142发送服务提供者列表变更订阅请求，如此，服务提供者发生变更时，设备142上部署的注册中心1420可以向设备104上部署的微服务调用装置1040发送针对服务提供者列表的变更消息。如此，设备104上的微服务调用装置1040在从服务提供者列表中确定提供所述第二服务的第二设备的地址时，可以根据变更后的服务提供者列表中确定提供所述第二服务的第二设备的地址，避免了向失效的服务提供者发送服务调用请求，提高了服务可靠性。

类似地，设备104上部署的微服务调用装置1040还可以向设备162发送服务治理规则变更订阅请求，如此，服务治理规则发生变更时，设备162的治理中心1620可以向设备104上部署的微服务调用装置1040发送针对服务治理规则的变更消息。如此，设备104上的微服务调用装置1040根据服务治理规则对所述第一数据运行服务治理逻辑时，可以根据变更后的服务治理规则对第一数据运行服务治理逻辑，从而进行服务治理。

还需要说明的是，上述场景仅是以设备102上部署的微服务为服务调用方，设备122上部署的微服务为服务被调用方进行示例说明。在一些实现方式中，设备122上部署的微服务也可以作为服务调用方，当其作为服务调用方时，微服务调用装置1240具有与微服务调用装置1040相类似的结构。此外，设备102上部署的微服务也可以作为服务被调用方，本申请实施例对此不作限定。

为了便于理解本申请的技术方案，下面将从第一服务、微服务调用装置1040、微服务调用装置1240、第二服务以及注册中心1420、治理中心1620和数据采集中心1820交互的角度对本申请实施例的微服务调用方法进行介绍。

参见图2所示的微服务调用方法的流程图，该方法包括：

S202：微服务调用装置1040订阅针对服务提供者列表的变更消息。

具体地，设备104上部署的微服务调用装置1040可以向设备142上的注册中心1420发送服务提供者列表变更订阅请求。服务提供者列表变更订阅请求用于请求订阅针对服务提供者列表的变更消息。该服务提供者列表变更订阅请求中包括设备104的标识。注册中心1420接收到该服务提供者列表变更订阅请求，可以将设备104的标识添加至订阅用户列表。当服务提供者列表发生变更时，注册中心1420可以将针对服务提供者列表的变更消息发送至订阅用户列表中的用户。如此，设备104上部署的微服务调用装置1040可以获得针对服务提供者列表的变更消息。

应理解，在一些实施例中，执行微服务调用方法也可以不执行S202。例如，微服务调用装置1040可以预先获取服务提供者列表，并根据该预先获取的服务提供者列表进行后续操作。

S204：微服务调用装置1040订阅针对服务治理规则的变更消息。

其中，服务治理是指在分布式服务框架下处理服务调用之间的关系，具体包括服务注册与发现、负载均衡、故障处理与恢复(限流、熔断、超时、重试)、灰度发布以及服务追踪等。基于此，治理中心1620可以定义服务治理的规则，也即服务治理规则。服务治理规则可以包括负载均衡的规则，故障处理与恢复的规则等等。

在具体实现时，设备104上部署的微服务调用装置1040可以向设备162上的治理中心1620发送服务治理规则变更订阅请求。服务治理规则变更订阅请求具体用于请求针对服务治理规则的变更消息。类似地，服务治理规则变更订阅请求中包括设备104的标识。治理中心1620接收到服务治理规则变更订阅请求时，将设备104的标识添加至订阅用户列表。当服务治理规则发生变更时，治理中心1620可以将针对服务治理规则的变更消息发送至订阅用户列表中的用户。如此，设备104上部署的微服务调用装置1040可以获得针对服务治理规则的变更消息。

需要说明，治理中心1620维护的订阅用户列表时针对服务治理规则的订阅用户列表，注册中心1420维护的订阅用户列表时针对服务提供者地址的订阅用户列表。也即治理中心1620和注册中心1420分别维护不同的订阅用户列表。

应理解，在一些实施例中，执行微服务调用方法也可以不执行S204。例如，微服务调用装置1040可以预先获取服务治理规则，并根据该预先获取的服务治理规则进行后续操作。

S206：设备102上部署的多个第一服务分别发送服务调用请求。

其中，多个第一服务(例如图1所示的服务11、服务12…服务1n)中的每个第一服务分别对应一个第二服务。该第二服务具体用于处理所述第二服务对应的第一服务所生成的服务调用请求的第一数据。

需要说明的是，第一数据具体是指需要第二服务进行处理的数据，每个发起服务调用请求的服务所需要处理的第一数据可以相同，也可以是不同的，具体可以根据实际需求确定。类似地，每个发起服务调用请求的第一服务所请求的第二服务可以相同，也可以不同，本申请实施例对此不作限定。

S208：微服务调用装置1040根据所述第一数据相关的服务治理逻辑确定提供所述第二服务的第二设备的地址。

第一服务发送的服务调用请求会经过设备104。设备104上部署的微服务调用装置1040接收到服务调用请求时，可以卸载服务调用请求的数据，得到第一数据。该第一数据至少包括数据包的包头，在有些情况下，第一数据还可以包括数据的包的包体。然后微服务调用装置1040基于S204订阅的针对服务治理规则的变更消息，以最新的(即最近一次变更后的)服务治理规则对第一数据运行服务治理逻辑，以从服务提供者列表中确定提供第二服务的第二设备的地址。

需要说明，在对第一数据运行服务治理逻辑，以从服务提供者列表中确定提供第二服务的第二设备的地址时，微服务调用装置1040可以基于S202订阅的针对服务提供者列表的变更消息，从最新的(即最近一次变更后的)服务提供者列表中确定提供第二服务的第二设备的地址。

应理解，执行微服务调用方法不执行S202时，微服务调用装置1040可以基于预先获取的服务提供者列表中确定提供第二服务的第二设备的地址。执行微服务调用方法不执行S204时，微服务调用装置1040可以基于预先获取的服务治理规则对第一数据运行服务治理逻辑。

其中，微服务调用装置1040根据服务治理规则对第一数据运行服务治理逻辑，即是根据服务治理规则对第一数据进行服务治理。为了便于理解，本申请还提供了一具体示例进行说明。在一个示例中，如图3所示，在电商系统的应用场景中，商品系统的一个微服务即服务11发起服务调用请求，服务调用请求指示采用评价系统中的评价获取服务即服务21对商品A这一数据进行处理，即获取针对商品A的历史评价。而提供评价获取服务的设备包括位于华东地区的设备1、位于华北地区的设备2、华南地区的设备3以及华中地区的设备4。设备1的流量负载和设备2的流量负载高于设备3和设备4的流量负载，其中，设备流量4的负载最小，则智能网卡上的微服务调用装置1040基于负载均衡规则确定设备4的地址为最终提供评价获取服务的设备的地址，向该地址的服务发送服务调用请求。

在实际应用时，微服务调用装置1040可以创建工作线程，即worker线程，通过该worker线程实现运行服务治理逻辑，以从服务提供者列表中确定提供第二服务的第二设备的地址的操作。

S210：微服务调用装置1040向治理中心1620发送流量检查请求。

在具体实现时，微服务调用装置1040可以将服务调用请求以及对应的第二设备的地址添加至流量检查队列，该流量检查队列具体为阻塞队列。然后微服务装置1040可以采用批量方式向治理中心1620发送流量检查请求。

具体地，微服务调用装置1040可以创建检查线程，即checker线程。checker线程可以从流量检查队列中取出所有等待流量检查的服务调用请求(设备102上部署的多个服务发起的多个服务调用请求)，生成流量检查请求，向治理中心1620发送该流量检查请求。如此，即实现将服务调用请求批量发送至治理中心1620。

S212：微服务调用装置1040接收治理中心1620返回的流量检查响应。当流量检查响应中的流量检查结果表征检查通过时，执行S214。

治理中心1620可以对微服务调用装置1040发送的流量检查请求中的多个服务调用请求进行批量地流量检查，例如通过检查源地址等确定上述服务调用请求为正常流量还是非法分子进行攻击产生的异常流量等。接着，治理中心1620可以根据流量检查结果生成流量检查响应，并向微服务调用装置1040返回流量检查响应。

需要说明的是，微服务调用装置1040接收到治理中心1620返回的流量检查响应后，checker线程还可以唤醒该批次服务调用请求对应的worker线程，然后阻塞流量检查队列中等待的新服务调用请求(即尚未发送至治理中心1620的服务调用请求)。

当微服务调用装置1040接收到的流量检查响应中流量检查结果表征检查通过时，微服务调用装置1040可以执行后续操作，例如执行S214。当服务调用装置1040接收到的流量检查响应中流量检查结果表征检查不通过时，微服务调用装置1040可以结束当前微服务调用流程。

应理解，S210和S212仅是为了提高安全性而实施的可选方式。在一些实施例中，执行微服务调用方法也可以不执行S210和S212。也即微服务调用装置1040可以在执行S208后执行S214。

S214：微服务调用装置1040根据第二设备的地址向第二服务发送服务调用请求。

在确定提供第二服务的第二设备的地址后，微服务调用装置1040可以根据将服务调用请求中的目的地址设置为上述提供第二服务的第二设备即设备122的地址，然后向第二服务发送服务调用请求。

其中，S208和S214是网卡上的微服务调用装置1040基于所述第一数据相关的服务治理逻辑，向所述第二服务发送所述服务调用请求的一种实现方式。在本申请实施例其他可能的实现方式中，微服务调用装置1040也可以通过其他方式向第二服务发送服务调用请求。

需要说明的是，当S208中确定的提供第二服务的第二设备的地址与S206中服务调用请求的目的地址不同时，S214中微服务调用装置1040发送的服务调用请求将不同于S206中发送的服务调用请求。其区别主要在于S214中发送的服务调用请求的目的地址为S208重新确定的提供第二服务的第二设备的地址。当然，在有些情况下，S214中发送的服务调用请求的包体也可以不同于S206中发送的服务调用请求的包体。

S216：微服务调用装置1240接收到上述服务调用请求时，向第二服务发送服务调用请求。

微服务调用装置1040向第二服务发送的服务调用请求经过设备124。设备124上部署的微服务调用装置1240接收到服务调用请求时，向第二服务发送服务调用请求。需要说明的是，考虑到网络异构性，微服务调用装置1240在接收到服务调用请求时，可以先卸载服务调用请求，然后基于卸载的数据重新生成服务调用请求，接着再向第二服务发送重新生成的服务调用请求。

S218：第二服务返回服务调用响应。

第二服务接收到服务调用请求时，可以响应于服务调用请求，对第一数据进行处理，得到第二数据。例如，服务调用请求指示评价系统中的评价获取服务对商品A进行处理，获取针对商品A的历史评价，则评价获取服务可以响应于该服务调用请求，从所有历史评价中获取针对商品A的历史评价。

第二服务可以根据第二数据生成服务调用响应，服务调用响应中携带上述第二数据，然后第二服务返回服务调用响应。

S220：微服务调用装置1240接收到服务调用响应时，向微服务调用装置1040发送服务调用响应。

第二服务返回的服务调用响应经过设备124。设备124上部署的微服务调用装置1240接收到服务调用响应时，向微服务调用装置1040发送服务调用响应。需要说明的是，与服务调用请求类似，微服务调用装置1240还可以在接收到服务调用响应时，先卸载服务调用响应，然后基于卸载后的数据重新生成服务调用响应，将该重新生成的服务服务调用响应发送至微服务调用装置1040，以便微服务调用装置1040能够识别所述服务调用响应。

S222：微服务调用装置1040向所述第二服务对应的第一服务发送服务调用响应。

具体地，微服务调用装置1040接收到服务调用响应时，可以卸载服务调用响应，然后基于卸载后的数据重新生成服务调用响应，并向第一服务发送重新生成的服务调用响应。

如此，第一服务实现了对第二服务的调用。需要说明的是，服务治理工作在设备104中完成，对业务逻辑无侵入。例如，对第二服务进行灰度发布时，第一服务的调用逻辑与第二服务的实现逻辑完全不用修改，灰度发布处理逻辑在设备104中完成即可。

S224：微服务调用装置1040向数据采集中心1820发送服务调用日志。

在一些可能的实现方式中，设备104上部署的微服务调用装置1040还可以根据接收到的服务调用请求和服务调用响应中的至少一个生成服务调用日志，然后以批量形式向数据采集中心1820发送服务调用日志。其中，微服务调用装置1040还可以设置日志上传周期，如此，微服务调用装置1040可以按照预设的日志上传周期以批量形式向数据采集中心1820发送服务调用日志。

S226：微服务调用装置1240向数据采集中心1820发送服务调用日志。

在一些可能的实现方式中，设备124上部署的微服务调用装置1240还可以根据接收到的服务调用请求和服务调用响应中的至少一个生成服务调用日志，然后按照预设周期以批量形式向数据采集中心1820发送所述服务调用日志。

微服务调用装置1040、微服务调用装置1240采用批量方式上传服务调用日志，可以减少设备104在数据面与数据采集中心1820交互的开销，以及减少设备124在数据面与数据采集中心1820交互的开销，节省成本。

其中，微服务调用装置1040根据接收到的服务调用请求和服务调用响应生成服务调用日志，微服务调用装置1240根据接收到的服务调用请求和服务调用响应生成服务调用日志，可以使得数据采集中心1820获取完整的日志追踪数据，包括第一服务发起服务调用请求的时间、第二服务接收到服务调用请求的时间、第二服务处理完成的时间以及第一服务接收到服务调用响应的时间。当某些微服务故障时，可以基于上述完整的日志追踪数据进行故障排除和故障维护。

应理解，S224、S226仅仅是本申请实施例提供的一种可选实施方式。在一些实施例中，执行微服务调用方法也可以不执行S2224和S2226。

图2中采用虚线或虚线框标识的步骤为本申请实施例提供的可选步骤，在有些可能的实现方式中，也可以不执行上述步骤，或者采用其他方式实现，本申请实施例对此不作限定。

基于上述内容描述，本申请实施例提供的微服务调用方法采用网卡代替服务网格中的代理，由网卡对一个设备上部署的不同服务发起的服务调用请求进行集中处理，完成服务治理工作，避免了对业务逻辑的侵入。此外，网卡可以对不同服务发起的服务调用请求进行集中处理，避免了不同服务竞争包括CPU在内的系统资源导致时延急剧增加的问题，降低了应用对资源的占用率，提高了应用响应效率，进而提升了应用性能。

上文中结合图1至图3，详细描述了本申请实施例所提供的微服务调用方法，下面将结合附图，描述根据本申请实施例所提供的微服务调用装置以及相应的设备。

参见图4所示的微服务调用装置的结构示意图，该微服务调用装置1040包括：

通信模块1042，用于接收第一设备上部署的多个第一服务分别生成的服务调用请求，所述多个第一服务中的每个第一服务分别对应一个第二服务，所述第二服务用于处理所述第二服务对应的第一服务所生成的服务调用请求的第一数据；

所述通信模块1042，还用于基于所述第一数据相关的服务治理逻辑，向所述第二服务发送所述服务调用请求。

在一些可能的实现方式中，所述通信模块1042具体用于：

根据所述第一数据相关的服务治理逻辑确定提供所述第二服务的第二设备的地址；

根据所述第二设备的地址向所述第二服务发送服务调用请求。

在一些可能的实现方式中，所述通信模块1042还用于：

向治理中心发送流量检查请求，所述流量检查请求用于针对N个服务调用请求进行流量检查，所述N为正整数；

接收所述治理中心发送的流量检查结果；

当所述流量检查结果表征检查通过时，执行向所述第二服务发送所述服务调用请求的步骤。

在一些可能的实现方式中，所述通信模块还用于：

接收所述第二服务发送的服务调用响应，所述服务调用响应包括所述第二服务对所述第一数据处理所得的第二数据；

所述装置1040还包括：

生成模块1044，用于根据所述服务调用请求和所述服务调用响应中的至少一个生成服务调用日志；

所述通信模块1042还用于：

以批量形式向数据采集中心发送所述服务调用日志。

在一些可能的实现方式中，所述装置1040还包括：

订阅模块1046，用于订阅针对服务提供者列表的变更消息，以从变更后的服务提供者列表中确定提供所述第二服务的第二设备的地址。

在一些可能的实现方式中，所述装置1040还包括：

订阅模块1046，用于订阅针对所述服务治理规则的变更消息；

服务治理模块1048，用于根据变更后的服务治理规则对所述第一数据运行服务治理逻辑。

在一些可能的实现方式中，所述网卡为智能网卡。

根据本申请实施例的微服务调用装置1040可对应于执行本申请实施例中描述的方法，并且微服务调用装置1040的各个模块的上述和其它操作和/或功能分别为了实现图2所示实施例中的各个方法的相应流程，为了简洁，在此不再赘述。

接下来，参见图5所示的微服务调用装置的结构示意图，该微服务调用装置1240包括：

通信模块1242，用于接收多个第一服务发送的服务调用请求，所述多个第一服务中的每个第一服务分别对应一个第二服务，所述第二服务用于处理所述第二服务对应的第一服务所生成的服务调用请求的第一数据；

所述通信模块1242，还用于向所述第二服务发送所述服务调用请求；

所述通信模块1242，还用于接收所述第二服务发送的服务调用响应，所述服务调用响应包括所述第二服务对所述第一数据处理所得的第二数据；

所述通信模块1242，还用于向所述第二服务对应的所述第一服务发送所述服务调用响应。

在一些可能的实现方式中，所述装置1240还包括：

生成模块1244，用于根据所述服务调用请求和所述服务调用响应中的至少一个生成服务调用日志；

所述通信模块1242，还用于以批量形式向数据采集中心发送所述服务调用日志。

在一些可能的实现方式中，所述网卡为智能网卡。

根据本申请实施例的微服务调用装置1240可对应于执行本申请实施例中描述的方法，并且微服务调用装置1240的各个模块的上述和其它操作和/或功能分别为了实现图2所示实施例中的各个方法的相应流程，为了简洁，在此不再赘述。

本申请实施例还提供了一种设备。该设备可以是网卡，具体用于实现如图4所示实施例中微服务调用装置1040的功能。

图6提供了一种设备的结构示意图，如图6所示，设备600包括总线601、处理器602、通信接口603和存储器604。处理器602、存储器604和通信接口603之间通过总线601通信。总线601可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。通信接口603用于与外部通信。例如，接收服务调用请求，发送服务调用请求等等。

其中，处理器602可以为中央处理器(central processing unit，CPU)。存储器604可以包括易失性存储器(volatile memory)，例如随机存取存储器(random accessmemory，RAM)。存储器604还可以包括非易失性存储器(non-volatile memory)，例如只读存储器(read-only memory，ROM)，快闪存储器，HDD或SSD。

存储器604中存储有可执行代码，处理器602执行该可执行代码以执行前述微服务调用方法。

具体地，在实现图4所示实施例的情况下，且图4实施例中所描述的微服务调用装置1040的各模块为通过软件实现的情况下，执行图4中的生成模块1044、订阅模块1046和服务治理模块1048功能所需的软件或程序代码存储在存储器604中。通信模块1042功能通过通信接口603实现。通信接口603接收第一设备上部署的多个第一服务分别生成的服务调用请求，将其通过总线601传输至处理器602，处理器602执行存储器604中存储的各模块对应的程序代码，执行微服务调用方法，以基于第一数据相关的服务治理逻辑，通过通信接口603向第二服务发送服务调用请求，从而实现微服务调用。

本申请实施例还提供了另一种设备。该设备可以是网卡，包括普通网卡或者智能网卡，具体用于实现如图5所示实施例中微服务调用装置1240的功能。

图7提供了一种设备的结构示意图，如图7所示，设备700包括总线701、处理器702、通信接口703和存储器704。处理器702、存储器704和通信接口703之间通过总线701通信。

存储器704中存储有可执行代码，处理器702执行该可执行代码以执行前述微服务调用方法。

具体地，在实现图5所示实施例的情况下，且图5实施例中所描述的微服务调用装置1240的各模块为通过软件实现的情况下，执行图5中的生成模块1244功能所需的软件或程序代码存储在存储器704中。通信模块1242功能通过通信接口703实现。通信接口703接收多个第一服务分别发送的服务调用请求，将其通过总线701传输至处理器702，处理器702执行存储器704中存储的各模块对应的程序代码，执行微服务调用方法。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质包括指令，所述指令指示网卡执行上述应用于微服务调用装置1040的微服务调用方法。

本申请实施例还提供了一种计算机可读存储介质，该计算机可读存储介质包括指令，所述指令指示网卡执行上述应用于微服务调用装置1240的微服务调用方法。

本申请实施例还提供了一种计算机程序产品，所述计算机程序产品被网卡执行时，所述网卡执行前述微服务调用方法的任一方法。该计算机程序产品可以为一个软件安装包，在需要使用前述微服务调用方法的任一方法的情况下，可以下载该计算机程序产品并在网卡上执行该计算机程序产品。

Claims (24)

1.一种微服务调用方法，其特征在于，所述方法包括：

网卡接收第一设备上部署的多个第一服务分别生成的服务调用请求，所述多个第一服务中的每个第一服务分别对应一个第二服务，所述第二服务用于处理所述第二服务对应的第一服务所生成的服务调用请求的第一数据；

所述网卡基于所述第一数据相关的服务治理逻辑，向所述第二服务发送所述服务调用请求。

2.根据权利要求1所述的方法，其特征在于，所述网卡基于所述第一数据相关的服务治理逻辑，向所述第二服务发送所述服务调用请求，包括：

所述网卡根据所述第一数据相关的服务治理逻辑确定提供所述第二服务的第二设备的地址；

所述网卡根据所述第二设备的地址向所述第二服务发送服务调用请求。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述网卡向治理中心发送流量检查请求，所述流量检查请求用于针对N个服务调用请求进行流量检查，所述N为正整数；

所述网卡接收所述治理中心发送的流量检查结果；

当所述流量检查结果表征检查通过时，执行向所述第二服务发送所述服务调用请求的步骤。

4.根据权利要求1所述的方法，其特征在于，所述方法还包括：

所述网卡接收所述第二服务发送的服务调用响应，所述服务调用响应包括所述第二服务对所述第一数据处理所得的第二数据；

所述网卡根据所述服务调用请求和所述服务调用响应中的至少一个生成服务调用日志；

所述网卡以批量形式向数据采集中心发送所述服务调用日志。

5.根据权利要求1至4任一项所述的方法，其特征在于，所述方法还包括：

所述网卡订阅针对服务提供者列表的变更消息，以从变更后的服务提供者列表中确定提供所述第二服务的第二设备的地址。

6.根据权利要求1至5任一项所述的方法，其特征在于，所述方法还包括：

所述网卡订阅针对所述服务治理规则的变更消息；

所述网卡根据变更后的服务治理规则对所述第一数据运行服务治理逻辑。

7.根据权利要求1至6任一项所述的方法，其特征在于，所述网卡为智能网卡。

8.一种微服务调用方法，其特征在于，所述方法包括：

网卡接收多个第一服务发送的服务调用请求，所述多个第一服务中的每个第一服务分别对应一个第二服务，所述第二服务用于处理所述第二服务对应的第一服务所生成的服务调用请求的第一数据；

所述网卡向所述第二服务发送所述服务调用请求；

所述网卡接收所述第二服务发送的服务调用响应，所述服务调用响应包括所述第二服务对所述第一数据处理所得的第二数据；

所述网卡向所述第二服务对应的所述第一服务发送所述服务调用响应。

9.根据权利要求8所述的方法，其特征在于，所述方法还包括：

所述网卡根据所述服务调用请求和所述服务调用响应中的至少一个生成服务调用日志；

所述网卡以批量形式向数据采集中心发送所述服务调用日志。

10.根据权利要求8或9所述的方法，其特征在于，所述网卡为智能网卡。

11.一种微服务调用装置，其特征在于，所述装置包括：

通信模块，用于接收第一设备上部署的多个第一服务分别生成的服务调用请求，所述多个第一服务中的每个第一服务分别对应一个第二服务，所述第二服务用于处理所述第二服务对应的第一服务所生成的服务调用请求的第一数据；

所述通信模块，还用于基于所述第一数据相关的服务治理逻辑，向所述第二服务发送所述服务调用请求。

12.根据权利要求11所述的装置，其特征在于，所述通信模块具体用于：

根据所述第一数据相关的服务治理逻辑确定提供所述第二服务的第二设备的地址；

根据所述第二设备的地址向所述第二服务发送服务调用请求。

13.根据权利要求11所述的装置，其特征在于，所述通信模块还用于：

向治理中心发送流量检查请求，所述流量检查请求用于针对N个服务调用请求进行流量检查，所述N为正整数；

接收所述治理中心发送的流量检查结果；

当所述流量检查结果表征检查通过时，执行向所述第二服务发送所述服务调用请求的步骤。

14.根据权利要求11所述的装置，其特征在于，所述通信模块还用于：

接收所述第二服务发送的服务调用响应，所述服务调用响应包括所述第二服务对所述第一数据处理所得的第二数据；

所述装置还包括：

生成模块，用于根据所述服务调用请求和所述服务调用响应中的至少一个生成服务调用日志；

所述通信模块还用于：

以批量形式向数据采集中心发送所述服务调用日志。

15.根据权利要求11至14任一项所述的装置，其特征在于，所述装置还包括：

订阅模块，用于订阅针对服务提供者列表的变更消息，以从变更后的服务提供者列表中确定提供所述第二服务的第二设备的地址。

16.根据权利要求11至15任一项所述的装置，其特征在于，所述装置还包括：

订阅模块，用于订阅针对所述服务治理规则的变更消息；

服务治理模块，用于根据变更后的服务治理规则对所述第一数据运行服务治理逻辑。

17.根据权利要求11至16任一项所述的装置，其特征在于，所述网卡为智能网卡。

18.一种微服务调用装置，其特征在于，所述装置包括：

通信模块，用于接收多个第一服务发送的服务调用请求，所述多个第一服务中的每个第一服务分别对应一个第二服务，所述第二服务用于处理所述第二服务对应的第一服务所生成的服务调用请求的第一数据；

所述通信模块，还用于向所述第二服务发送所述服务调用请求；

所述通信模块，还用于接收所述第二服务发送的服务调用响应，所述服务调用响应包括所述第二服务对所述第一数据处理所得的第二数据；

所述通信模块，还用于向所述第二服务对应的所述第一服务发送所述服务调用响应。

19.根据权利要求18所述的装置，其特征在于，所述装置还包括：

生成模块，用于根据所述服务调用请求和所述服务调用响应中的至少一个生成服务调用日志；

所述通信模块，还用于以批量形式向数据采集中心发送所述服务调用日志。

20.根据权利要求18或19所述的装置，其特征在于，所述网卡为智能网卡。

21.一种网卡，其特征在于，所述网卡包括处理器和存储器；

所述处理器用于执行所述存储器中存储的指令，以使得所述网卡执行如权利要求1至7中任一项所述的微服务调用方法。

22.一种网卡，其特征在于，所述网卡包括处理器和存储器；

所述处理器用于执行所述存储器中存储的指令，以使得所述网卡执行如权利要求8至10中任一项所述的微服务调用方法。

23.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括指令，所述指令指示网卡执行如权利要求1至7中任一项所述的微服务调用方法。

24.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质包括指令，所述指令指示网卡执行如权利要求8至10中任一项所述的微服务调用方法。

Images