具体实施方式

下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本公开的实施方式，提出了一种云计算数据交互方法、云计算数据交互系统、电子设备及计算机可读存储介质。

在本文中，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。

发明概述

在与云计算数据交互有关的相关技术中，为了应对由于微服务之间的通信链路复杂度上升的问题，采用了边车代理程序来将某些应用功能从应用本身剥离出来作为单独进程运行，从而实现降低与微服务架构相关的复杂性。举例来说，如图1所示，微服务A 101与微服务B 102之间从直接通信变为通过各自的边车代理程序C 103和边车代理程序D 104来进行通信，其中边车代理程序C 103和边车代理程序D 104以进程的方式存在，并且与各自的微服务A 101和微服务B 102之间通过socket类函数进行通信；此外，边车代理程序C 103和边车代理程序D 104通过iptables组件(也称为用户空间，是一种IP信息包过滤系统)劫持微服务A 101与微服务B 102的收发数据来实现服务治理。

然而，引入边车代理程序造成了微服务A 101与微服务B 102之间的通信路径变长。如图2所示，在单次发送报文的情况下，如果微服务A 201与微服务B 202直接通信而无需通过环回(loopback)接口调用边车代理程序，则仅需调用两次内核TCP/IP协议栈205；然而，在引入边车代理程序203和204之后，除上述内核TCP/IP协议栈205之外，还要额外调用四次内核TCP/IP协议栈206。而在响应报文的情况下，也需要重复上述过程才能够将报文从响应方发送至接收方。因此，对内核TCP/IP协议栈206的频繁调用造成了在基于iptables组件实现的用户态与内核态之间频繁地切换，而内核协议栈在运行时也会占用大量的CPU资源。

如图3中的火焰图300所示，在使用fortio来测试名为envoy的边车代理程序对CPU资源的占用的场景下，边车代理程序执行转发等动作所占用的CPU资源与内核协议栈占用的CPU资源之比接近于1:1。因此，由于运行内核协议栈所造成的资源开销对与引入边车代理程序有关的时延增加起到了不可忽视的作用。而时延往往是用户非常关注的一个业务指标，时延增加会严重影响用户的业务体验。

发明人发现，通过使边车代理程序通过用户态通信接口将劫持到的报文发送至包括用户态TCP/IP协议栈和报文卸载技术栈的协议加速进程，并且使协议加速进程调用用户态TCP/IP协议栈并通过报文卸载技术栈在用户态下对报文进行发送，可以较好地解决上述问题，进而降低由边车代理程序带来的时延增加。

基于上述内容，本公开的基本思想在于：将由于引入边车代理程序而额外引入的对内核TCP/IP协议栈的调用转换为调用用户态TCP/IP协议栈，从而避免由于运行内核TCP/IP协议栈带来的额外CPU资源占用；此外，可以将对应于各个边车代理程序的用户态TCP/IP协议栈和报文卸载技术栈整合为单独的进程，使得该单个进程在收发报文进行轮询时占用的CPU资源处于可接受的较低水平。

本公开技术方案能够将各个边车代理程序在进行报文收发时所调用的TCP/IP协议由在内核态下实现转换为在用户态下实现，避免了在数据交互过程中由于多次调用内核TCP/IP协议栈而造成在内核态与用户态之间频繁切换，从而通过一种无侵入的、和应用分离的、支持双栈的用户态协议栈减少了系统对内核TCP/IP协议栈的调用，并相应地降低了CPU资源开销，因而显著降低了由边车代理程序带来的时延。另一方面，通过将报文收发过程中所调用的用户态TCP/IP协议栈和报文卸载技术栈整合为单独的协议加速进程，使得该协议加速进程占用的CPU资源可控，因而进一步降低了CPU资源的占用，而节省出的CPU资源则可以调配给边车代理程序使用，从而还能够提升边车代理程序的性能，降低处理时延。

在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。

应用场景概览

需要注意的是，下述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。

如图4所示，根据本公开的云计算数据交互方法可应用于在同一服务器410上运行的不同微服务401和402之间的数据交互，该微服务401和402各自调用用于服务治理的边车代理程序403和404。在该服务器410上还可以运行有与各微服务一一对应的、用于承载各微服务的多个POD；其中，POD是指按照服务或功能划分的一个或多个容器的集合，而容器是指一种能够将单个操作系统的资源和应用程序划分并加载到孤立的存储器组中的虚拟化技术。也就是说，根据本公开的方法可以应用于在服务器410上运行的不同POD之间的数据交互。

此外，根据本公开的云计算数据交互方法还可应用于服务器集群450中的不同服务器420与430之间的数据交互，更进一步地，用于分别运行在不同服务器420与430上的不同微服务405和406之间的数据交互，该微服务405和406各自调用用于服务治理的边车代理程序407和408。其中，服务器420与430之间能够通过通信网络440进行通信传输。在本公开的后续说明中，以Linux操作系统为例来作为各微服务的示例性运行环境。

通过本公开实施方式的云计算数据交互方法，可以降低由于引入边车代理程序而带来的时延，从而提高微服务之间数据交互的效率。

示例性方法

参考图5来描述根据本公开示例性实施方式的一个方面的云计算数据交互方法。

本示例实施方式提供了一种云计算数据交互方法，应用于服务器或服务器集群。参考图5所示，该云计算数据交互方法可以包括以下步骤：

步骤S510.调用边车代理程序，并通过所述边车代理程序劫持由微服务发送的报文；

步骤S520.使所述边车代理程序调用应用适配动态链接库，所述应用适配动态链接库包括用户态通信接口；

步骤S530.使所述应用适配动态链接库通过所述用户态通信接口将劫持到的所述报文转发至协议加速进程，其中，所述协议加速进程包括用户态TCP/IP协议栈和报文卸载技术栈；

步骤S540.使所述协议加速进程调用所述用户态TCP/IP协议栈并且通过所述报文卸载技术栈在用户态下对所述报文进行发送。

在上述提供的云计算数据交互方法中，可以对用于劫持报文的边车代理程序配备应用适配动态链接库，从而能够以一种对边车代理程序无侵入的方式使边车代理程序将所劫持到的报文通过应用适配动态链接库所包括的用户态通信接口发送至协议加速进程；而该协议加速进程可以包括用户态TCP/IP协议栈和报文卸载技术栈，从而在需要调用TCP/IP协议时可以调用该用户态TCP/IP协议栈，并且该报文卸载技术栈能够在用户态下对报文进行发送。通过该云计算数据交互方法，能够减少系统对内核TCP/IP协议栈的调用，并相应地降低了系统的CPU资源开销，因而显著降低由边车代理程序带来的时延，提高数据交互效率；并且还能够控制报文卸载技术栈的CPU资源开销，进一步降低资源占用。

下面，在另一实施例中，对上述步骤进行更加详细的说明。

在步骤S510中，调用边车代理程序，并通过所述边车代理程序劫持由微服务发送的报文。

在本示例实施方式中，除各种微服务之外，在服务器上还可以运行有多个边车代理程序。这些边车代理程序可以响应于程序代码行或指令而被调用，并以松耦合和无侵入的方式附加到相应的微服务上，并且对该微服务的所有接收和发送的网络流量均进行代理，从而完成微服务之间的流量管理、遥测数据收集以及策略的执行等等。这种通过代理而将微服务的发送和接收的数据(例如，报文)转由自身进行处理交互的过程，可以叫做“劫持”。

如图6所示，在应用了根据本公开的云计算数据交互方法的微服务通信链路中，可以将微服务601发送的报文发送至通信网络605，此时报文中携带的IP地址为接收端微服务602的IP地址；然后可以利用由iptables组件实现的DNAT(Destination Network AddressTranslation，目标地址转换，用于根据指定条件修改数据包的目标IP地址或目标端口)策略来将报文中的微服务602的IP地址转换为边车代理程序603的IP地址；此时则报文可以从通信网络605侧被转发至边车代理程序603处，从而实现通过边车代理程序603劫持由微服务601所发送的报文。并且在将报文转发至边车代理程序603的过程中，当需要调用TCP/IP协议栈时，可以实现调用用户态TCP/IP协议栈610，而不是如相关技术中调用内核态TCP/IP协议栈来实现报文到边车代理程序的发送过程。相应地，在接收端微服务602接收报文时，可通过上述的报文发送过程的反向过程来接收报文，其中边车代理程序604在将报文转发至微服务602的过程中，所调用的TCP/IP协议栈620同样为用户态TCP/IP协议栈。通过这种方式，在微服务601与微服务602之间的通信链路中，至少TCP/IP协议栈610和620可以被优化为用户态TCP/IP协议栈。

在步骤S520中，使所述边车代理程序调用应用适配动态链接库，所述应用适配动态链接库包括用户态通信接口。

在本示例实施方式中，为了在用户态下对由边车代理程序劫持到的报文进行处理和发送，可以设置应用适配动态链接库并将其设置成包括用户态通信接口，并且可以使边车代理程序调用该应用适配动态链接库，使得所劫持到的报文能够通过该用户态通信接口被转发至用户空间并处理。通过应用适配动态链接库，可以以无侵入的方式为边车代理程序配置一功能性函数库，从而使得可以无需更改边车代理程序本身的代码而同时可以实现将由边车代理程序劫持的报文转发至用户空间中。

在一个示例中，如图7所示，应用适配动态链接库702可以包括应用适配模块7021，而该应用适配模块7021可以包括被边车代理程序调用的socket类函数，其中，socket类函数例如可以包括socket、bind、listen等函数，边车代理程序可以通过调用socket类函数而与其他进程或程序建立通信连接，从而实现信息交互。而通过包括被边车代理程序调用的socket类函数，应用适配模块7021相当于提供了与边车代理程序建立通信连接的接口，也就是说，应用适配模块7021能够对边车代理程序对socket类函数的调用进行劫持，从而使得边车代理程序能够将所劫持到的报文通过借由socket类函数建立的通信连接而转发至用户空间中。

一种典型的服务端应用适配模块的伪码例如可以为：

而当需要对边车代理程序对socket类函数的调用进行劫持时，可以对应用适配模块进行定义，例如可以定义成：

socket类函数可以基于上述定义形式而被包含在应用适配模块7021中，当边车代理程序对该socket类函数进行调用以建立通信连接时，即可通过应用适配模块7021与应用适配动态链接库702实现通信连接。

此外，为了确保边车代理程序对socket类函数进行调用时优先调用被包含在应用适配动态链接库中的socket类函数，从而确保能够将所劫持到的报文转发至用户空间中，可以采用LD_PRELOAD机制来使得边车代理程序在启动时被指定加载应用适配动态链接库，也就是说，使得应用适配动态链接库的被加载顺序优先级最高。举例来说，可以以下述方式来实现：

1).实现应用适配动态链接库；以应用适配动态链接库中包括的epoll_wait函数为例，可以包括：

a).在.c文件中定义和实现包裹函数：

int

epoll_wait(int epfd,struct epoll_event*events,int maxevents,int

timeout){

return XXX_epoll_wait(epfd,events,maxevents,timeout)；

}

b).通过在.h文件中做如下声明将epoll_wait函数符号表导出，供边车代理程序加载应用适配动态链接库后调用：

extern int

epoll_wait(int epfd,struct epoll_event*events,int maxevents,inttimeout)；

c).将.c和.h文件编译成应用适配动态链接库，例如命名为libadapter.so；

2).在边车代理程序启动时通过LD_PRELOAD环境变量指定应用适配动态链接库的IP地址，例如边车代理程序被命名为envoy，则启动边车代理程序的指令行可以由

envoy--concurrency 2-c envoy.yaml

改变为：

LD_PRELOAD＝libadapter.so envoy--concurrency 2-c envoy.yaml。

通过这种方式，使得边车代理程序在启动时会优先加载名为libadapter.so的应用适配动态链接库，进而使得当边车代理程序调用socket类函数时，可以优先调用应用适配动态链接库中的socket类函数。

通过上述示例，能够以对边车代理程序无侵入的方式实现使边车代理程序优先调用应用适配动态链接库，避免了修改边车代理程序本身的代码，保证了边车代理程序的通用性并降低了人力编码成本；在此基础上，进一步使得应用适配动态链接库实现了劫持边车代理程序所调用的socket类函数，从而实现了能够通过应用适配动态链接库来将被边车代理程序劫持的报文转发至用户空间，以便于后续的处理与发送。

在步骤S530中，使所述应用适配动态链接库通过所述用户态通信接口将劫持到的所述报文转发至协议加速进程，其中，所述协议加速进程包括用户态TCP/IP协议栈和报文卸载技术栈。

在本示例实施方式中，如图7所示，应用适配动态链接库702可以包括适配通信模块7023，其用于与协议加速进程703进行通信以便转发或者接收报文或报文通知。以epoll_wait函数为例，适配通信模块7023可以通过该函数对报文通知队列进行处理，并且边车代理程序也可以持续调用该函数来对报文通知进行处理，因此该适配通信模块7023的伪代码例如可以实现为：

相应地，协议加速进程703也可以包括用于与适配通信模块7023进行通信的加速通信模块7031，该加速通信模块7031可以采用polling轮询模式来对报文进行处理，其伪代码例如可以实现为：

因此，应用适配动态链接库702可以通过用户态通信接口以及适配通信模块7023将劫持到的报文经由加速通信模块7031发送至协议加速进程703。此外，协议加速进程703还可以包括用户态TCP/IP协议栈7032和报文卸载技术栈7033，其中该报文卸载技术栈7033例如可以为数据平面开发套件(DPDK)，其可以运行在用户空间上并利用自身提供的数据平面库来收发数据包，从而绕过了内核协议栈对数据包的处理过程，并因而能够实现将报文直接拷贝到用户空间或在用户空间中执行报文发送。

在步骤S540中，使所述协议加速进程调用所述用户态TCP/IP协议栈并且通过所述报文卸载技术栈在用户态下对所述报文进行发送。

在本示例实施方式中，在从应用适配动态链接库接收到转发的报文之后，协议加速进程则可以调用自身的用户态TCP/IP协议栈，并且通过自身的报文卸载技术栈，例如数据平面开发套件，在用户态下将报文发送至接收端微服务侧。

如图6所示，在应用了根据本公开的云计算数据交互方法的微服务通信链路中，对于报文发送端而言，由微服务601发送的报文通过上文所述的方式被转发至边车代理程序603之后，则边车代理程序603可以调用与之对应的应用适配动态链接库630，并使该应用适配动态链接库630通过用户态通信接口将报文转发至协议加速进程650，而该协议加速进程650则可以调用自身的用户态TCP/IP协议栈并且通过自身的报文卸载技术栈在用户态下将报文发送至通信网络605。而对于报文接收端而言，对报文进行接收的过程对应于报文发送过程的反向过程，协议加速进程650可以通过自身的报文卸载技术栈将从通信网络605接收到的报文卸载至用户空间中，并调用自身的用户态TCP/IP协议栈将报文转发至与接收端边车代理程序604对应的应用适配动态链接库640，而该应用适配动态链接库640则可以通过自身的用户态通信接口将报文转发至边车代理程序604，该边车代理程序604可以调用用户态TCP/IP协议栈620将报文发送至通信网络605，并且在通过DNAT策略转换IP地址后报文从通信网络605侧被发送至接收端微服务602处。

如上所述，在如图6所示的通信链路中，相对于相关技术，TCP/IP协议栈610和620已被优化为用户态TCP/IP协议栈；而在通过根据本公开的协议加速进程650将报文发送至通信网络605以及从通信网络接收报文的过程中，两次所调用的TCP/IP协议栈均为协议加速进程650所包括的用户态TCP/IP协议栈。因此，相对于如图2所示的相关技术的通信链路，其中的对内核TCP/IP协议栈206的四次调用已被优化为对用户态TCP/IP协议栈的四次调用。由此，在从发送端到接收端的一次单向报文通信中，通过本公开的云计算数据交互方法实现了服务网格的数据面通信加速，反之亦然。

在本公开示例实施方式所提供的云计算数据交互方法中，能够将各个边车代理程序在进行报文收发时所调用的TCP/IP协议由在内核态下实现转换为在用户态下实现，避免了在数据交互过程中由于多次调用内核TCP/IP协议栈而造成在内核态与用户态之间频繁切换，从而通过一种无侵入的、和应用分离的、支持双栈的用户态协议栈减少了系统对内核TCP/IP协议栈的调用，并相应地降低了CPU资源开销，因而显著降低了由边车代理程序带来的时延。另一方面，通过将报文收发过程中所调用的用户态TCP/IP协议栈和报文卸载技术栈整合为单独的协议加速进程，使得该协议加速进程占用的CPU资源可控，因而进一步降低了CPU资源的占用，而节省出的CPU资源则可以调配给边车代理程序使用，从而还能够提升边车代理程序的性能，降低处理时延。

根据本公开的一个实施例，单个协议加速进程可用于与多个应用适配动态链接库进行通信，从而能够将与这多个应用适配动态链接库对应的多个边车代理程序所劫持到的报文发送至接收端微服务侧。如图7所示，多个边车代理程序701可以各自对应于一个应用适配动态链接库702，也就是说，各边车代理程序701可以分别加载对应的应用适配动态链接库702并调用其中的socket类函数，以便将从相应的微服务端劫持到的报文转发至用户空间；而各应用适配动态链接库702则可以与同一个协议加速进程703进行通信并转发报文，以使得该协议加速进程703通过调用自身的用户态TCP/IP协议栈并且通过报文卸载技术栈在用户态下发送报文。

通过上述实施例，优化了在每个承载微服务的POD中均部署一个报文卸载技术栈(例如，数据平面开发套件)的架构，也就是说，不将报文卸载技术栈集成在应用适配动态链接库中，而是使报文卸载技术栈与应用适配动态链接库分离部署，使得包括该报文卸载技术栈的协议加速进程在每台物理服务器上只会启动一个，从而解决了由于数据平面开发套件在polling轮询模式下会独占内核资源，因而多个微服务同时运行时会大量占用CPU资源的问题，实现了CPU资源的优化统筹管理，并有效降低了CPU资源的占用率。

根据本公开的另一个实施例，应用适配动态链接库还可以包括内核态通信接口。在某些情况下，例如当需要对服务器进行健康状况检查时，通过边车代理程序劫持到的报文或指令则需要通过环回接口发送至特定的内核态协议栈。因此，由于应用适配动态链接库起到对由边车代理程序劫持到的报文进行转发的作用，该应用适配动态链接库需要被实现为能够同时支持用户态协议栈和内核态协议栈的通信需求。在这种情况下，如图7所示，应用适配动态链接库702还可以包括双栈选路模块7022，该双栈选路模块7022能够确定将所劫持到的报文通过用户态通信接口还是内核态通信接口来转发至相应的用户态协议栈或内核态协议栈。当确定调用用户态通信接口转发报文时，则可以使应用适配动态链接库702将报文转发至协议加速进程703；而当确定调用内核态通信接口转发报文时，则可以使应用适配动态链接库702将报文转发至相应的内核态协议栈。

通过上述实施例，应用适配动态链接库能够兼顾微服务对用户态协议栈和内核态协议栈的通信需求，使得应用适配动态链接库具有良好的通用性，并且使得当需要与内核态协议栈进行通信时，边车代理程序无需调用额外的函数或动态链接库，从而降低了服务网格数据面的复杂度和通信信令开销，提高了通信效率。

根据本公开的又一个实施例，双栈选路模块7022可以根据边车代理程序所劫持到的报文中携带的目的IP地址来确定要调用用户态通信接口还是内核态通信接口来转发报文。例如可以预先设置不同的IP地址段分别对应于用户态通信接口或内核态通信接口；举例来说，可以将192.168.1.xx地址段设置为对应于用户态通信接口，可以将192.168.2.xx地址段设置为对应于内核态通信接口；这样例如当解析出报文中携带的目的IP地址为192.168.1.0/24时，则确定调用用户态通信接口来转发报文，相应地，例如当解析出报文中携带的目的IP地址为192.168.2.0/24时，则确定调用内核态通信接口来转发报文。

另外，在微服务之间的通信过程中，根据通信需求，通信双方的微服务可以分别属于客户侧或服务侧，例如，微服务A发送指令指示微服务B反馈参数，则其中微服务A属于客户侧，而微服务B属于服务侧。而各微服务可以根据自身属于客户侧还是服务侧而通过不同的函数来建立通信连接。举例来说，作为客户侧的微服务A可以通过connect函数来指定目的微服务并与服务侧的微服务B建立通信连接，而作为服务侧的微服务B则可以通过bind函数来监听客户侧微服务的连接请求并与客户侧的微服务A建立通信连接。在通过边车代理程序进行代理的场景下，在调用connect或bind函数之前，微服务A或微服务B可以通过边车代理程序调用socket接口以便后续通过connect或bind函数建立通信连接。然而，在调用socket接口时，交互的信令中不会携带IP地址，则此时无法判断要通过用户态通信接口还是内核态通信接口来发送报文，因此可以同时建立用户态socket接口以及内核态socket接口；而在完成调用socket接口后，微服务在通过connect或bind函数建立通信连接过程中的信令中则可以携带IP地址，例如：在指定目的微服务的连接请求中可以携带目的微服务的IP地址，或者在服务侧的微服务监听到的连接请求中可以携带发起请求的微服务的IP地址；此时可以由双栈选路模块7022根据解析出的IP地址所属的地址段来确定通过用户态通信接口还是内核态通信接口来转发报文。在确定所选择的通信接口之后，例如选择通过内核态通信接口来转发报文，则在转发动作之后可以相应地删除所建立的用户态通信接口，而如果选择通过用户态通信接口来转发报文，则在转发动作之后可以相应地删除所建立的内核态通信接口。

图8示出了上述双栈选路模块7022确定通过用户态通信接口或内核态通信接口来发送报文的总体流程。其中：

在S801，双栈选路模块可以调用socket函数；

在S802，双栈选路模块可以同时建立用户态socket接口和内核态socket接口；

在S803，当与双栈选路模块对应的微服务为客户侧的微服务时，该微服务可以通过connect函数来指定目的微服务的IP地址；在这种情况下，双栈选路模块可以对connect函数进行解析；

在S804，双栈选路模块可以判别所解析出的目的IP地址是否属于用户态的IP地址段，例如192.168.1.xx；

在S805，如果目的IP地址属于用户态的IP地址段，则选择通过用户态socket接口来对报文进行转发，并相应地删除之前建立的内核态socket接口；

在S806，如果目的IP地址属于内核态的IP地址段，则选择通过内核态socket接口来对报文进行转发，并相应地删除之前建立的用户态socket接口；

在S807，当与双栈选路模块对应的微服务为服务侧的微服务时，该微服务可以通过bind函数来监听客户侧的微服务的连接请求并相应地建立通信连接；在这种情况下，双栈选路模块可以对bind函数进行解析；

在S808，双栈选路模块可以判别所监听到的IP地址是否属于用户态的IP地址段，例如192.168.1.xx；

在S809，如果所监听到的IP地址属于用户态的IP地址段，则选择通过用户态socket接口来对报文进行转发，并相应地删除之前建立的内核态socket接口；

在S810，如果所监听到的IP地址属于内核态的IP地址段，则选择通过内核态socket接口来对报文进行转发，并相应地删除之前建立的用户态socket接口。

通过上述实施例，能够根据报文中携带的目的IP地址来选择通过用户态通信接口还是内核态通信接口对报文进行转发，使得微服务能够通过双栈选路模块实时地以及高效地与相应的用户态协议栈或内核态协议栈进行通信，而免除了复杂的判断逻辑或判断代码，进而提高了双栈选路模块以及应用适配动态链接库的代码可读性、易用性以及通用性。

下面参考图9来描述根据本公开示例性实施方式的另一个方面的云计算数据交互方法。

本示例实施方式提供了一种云计算数据交互方法，应用于服务器或服务器集群。参考图9所示，该云计算数据交互方法可以包括以下步骤：

步骤S910.调用边车代理程序，并使所述边车代理程序调用应用适配动态链接库，所述应用适配动态链接库包括用户态通信接口；

步骤S920.调用协议加速进程，所述协议加速进程包括用户态TCP/IP协议栈和报文卸载技术栈，并使所述协议加速进程调用所述用户态TCP/IP协议栈并且通过所述报文卸载技术栈在用户态下对报文进行接收；

步骤S930.使所述应用适配动态链接库通过所述用户态通信接口从所述协议加速进程接收报文，并将接收到的所述报文传递至所述边车代理程序；

步骤S940.使所述边车代理程序将所述报文转发至微服务。

在上述提供的云计算数据交互方法中，可以调用边车代理程序来对微服务的数据交互，尤其是报文接收进行代理，并且可以调用协议加速进程，该协议加速进程可以包括用户态TCP/IP协议栈和报文卸载技术栈，从而在需要调用TCP/IP协议时可以调用该用户态TCP/IP协议栈，并且该报文卸载技术栈能够在用户态下对报文进行接收；可以对边车代理程序配备应用适配动态链接库，该应用适配动态链接库可以包括用户态通信接口并且可以通过该用户态通信接口从协议加速进程接收报文，进而能够以一种对边车代理程序无侵入的方式使边车代理程序从协议加速进程接收报文。通过该云计算数据交互方法，能够减少系统对内核TCP/IP协议栈的调用，并相应地降低了系统的CPU资源开销，因而显著降低了由边车代理程序带来的时延，提高数据交互效率；并且还能够控制报文卸载技术栈的CPU资源开销，进一步降低资源占用。

上述提供的云计算数据交互方法从报文接收端进行了限定和说明，与在上文从报文发送端进行限定和说明的云计算数据交互方法相比，实现原理与实现手段对应相似，为了避免重复说明，在此不再赘述。

根据本公开的一个实施例，在对发送端微服务发送的报文进行接收的过程中，协议加速进程可以调用自身的用户态TCP/IP协议栈并且通过报文卸载技术栈将报文卸载到用户空间，之后可以通过自身的加速通信模块将报文转发给应用适配动态链接库的适配通信模块。在该转发的过程中，加速通信模块可以采用内核态的eventfd通知机制，也就是说，加速通信模块可以向适配通信模块分别发送报文通知和报文数据，其中报文通知用于通知接收端的边车代理程序当前存在待接收的报文数据，从而使接收端的边车代理程序调用read类接口去对与报文通知对应的报文数据进行处理和接收；而在发送报文通知和报文数据之后，加速通信模块可以向适配通信模块再发送一个事件通知，即，eventfd通知，该eventfd通知可以被适配通信模块转发至双栈选路模块，并用于触发双栈选路模块对报文通知和报文数据进行接收的动作或事件。而双栈选路模块可以监听并接收该eventfd通知，当接收到该eventfd通知时，则双栈选路模块可以被唤醒并且从适配通信模块接收报文通知和相应的报文数据。

通过上述实施例，能够在用户态下实现事件触发(例如报文接收通知)的机制，从而能够在不依赖额外编码的情况下实现用户空间中的进程之间的等待和唤醒通知机制，进而实现进程间的数据交互。通过这种方式，能够降低代码编写人员的人工负荷，并相应实现程序编码轻量化。

根据本公开的一个进一步的实施例，双栈选路模块可以采用epoll_wait函数来对eventfd通知进行监听，并可以对该epoll_wait函数设置等待时间，还可以通过检查该等待时间是否到期来模拟内核态的epoll_wait函数的等待超时的情况；如果在epoll_wait函数的等待时间内监听到该eventfd通知，则双栈选路模块可以被唤醒并对报文通知和报文数据进行接收。在此情况下，如果加速通信模块在每次发送报文通知时都发送eventfd通知，则会造成频繁地调用内核态，因此增加了CPU资源的占用并从而对性能造成不良影响。

为此，可以以下述方式对基于eventfd通知的事件触发机制进行设置：可以在双栈选路模块中设置报文通知队列(例如可以命名为Q_N队列)和报文数据队列(例如可以命名为Q_D队列)，其中该报文通知队列和报文数据队列可以基于共享大页内存的无锁队列来实现，并且可以仅在该报文通知队列中的报文通知的数量从0变为大于等于1的正整数时才触发eventfd通知。对此，可以将双栈选路模块设置成在处理报文通知队列中的报文通知时，一次性地接收全部报文通知，并进而接收报文数据队列中的与这些报文通知对应的报文数据，以便避免后续即使加速通信模块发送了新的报文通知也不会触发eventfd通知，进而导致双栈选路模块由于监听不到eventfd通知而不会对报文通知队列进行处理。

此外，考虑到报文通知队列中的报文通知的数量可能超出epoll_wait函数中events列表的事件个数限制，从而使双栈选路模块无法一次性处理所有的报文通知，还可以在双栈选路模块中设置通知缓存队列(例如可以命名为Q_N_C队列)。当出现单次待接收的报文通知的数量过多的情况时，可以将超过events列表的事件个数限制的，也就是超过双栈选路模块的接收上限的报文通知缓存在该通知缓存队列中，以便在epoll_wait函数下一次监听到eventfd通知时优先处理该通知缓存队列中的报文通知，并进而接收报文数据队列中的与这些报文通知对应的报文数据。另外，除了上述的eventfd通知之外，还可以以其他方式来实现报文通知机制，例如通过管道等来实现，本实施例对此不做特别限定。

通过上述实施例，在实现了用户态下的事件触发机制的基础上，通过设置报文通知队列和报文数据队列并设置成一次性接收全部报文通知，进一步优化了对内核态的调用频率，从而降低了事件触发机制对系统性能的不良影响。另一方面，通过设置通知缓存队列，解决了由于一次性接收全部报文通知而可能造成的报文通知溢出的问题，在能够保证报文收发动作正常运行的同时增强了系统的鲁棒性。

根据本公开的一个实施例，与发送端的情况类似，在接收端可能也存在需要对服务器进行健康状况检查从而需要通过内核态通信接口将报文转发至内核态协议栈的情况。对此，双栈选路模块可以通过实现在接收报文的过程中对内核态epoll fd和用户态epollfd进行同时监听来确定要调用用户态通信接口还是内核态通信接口来对报文进行转发，其中，epoll是一种用于处理大批量句柄的多路I/O就绪通知函数。举例来说，同时监听内核态epoll fd和用户态epoll fd可以通过epoll fd嵌套的方式来实现，具体如下：

将与eventfd通知对应的epoll fd，也就是与用户态下的报文接收事件的触发通知对应的第一epoll fd加入到与当前的epoll_wait函数对应的第二epoll fd中，从而得到同时包括第一epoll fd和第二epoll fd的复合的第三epoll fd；

在应用适配动态链接库的双栈选路模块通过epoll_wait函数来监听事件触发通知时，无需使epoll_wait函数同时对第一epoll fd和第二epoll fd进行监听，而是可以使epoll_wait函数对上述第三epoll fd进行监听即可；当该epoll_wait函数返回了大于零的返回值(在本实施例中例如为1)，也就是说，在当前等待时间内存在被触发的事件时，则与该事件对应的文件描述符的状态则会发生变化，例如缓冲区由不可读变为可读，或者由不可写变为可写；在这种情况下，例如可以通过events参数来确定是第三epoll fd中的第一epoll fd还是第二epoll fd的状态发生了变化，即确定与被触发的事件对应的epoll fd；

如果检测到状态发生变化的文件描述符为第一epoll fd，也就是说，被触发的事件为接收到eventfd通知，则相应地可以确定双栈选路模块通过epoll_wait函数监听并接收到了由加速通信模块发送的eventfd通知。如果检测到状态发生变化的文件描述符为第二epoll fd，则相应地可以确定所被触发的事件为应被转发至内核态协议栈的事件。

图10示出了应用适配动态链接库的双栈选路模块通过epoll_wait函数来监听用户态事件触发的总体流程。其中：

在S1001，双栈选路模块可以调用epoll_wait函数；

在S1002，双栈选路模块可以确定第一epoll fd是否已被加入到第二epoll fd中，也就是说，确定是否已将与eventfd通知对应的epoll fd加入到与当前的epoll_wait函数对应的epoll fd中；

在S1003，如果并未加入，则将第一epoll fd加入到第二epoll fd中，之后跳转至S1004；

在S1004，在确定第一epoll fd已被加入到第二epoll fd中的情况下，双栈选路模块可以确定通知缓存队列是否为空；

如果为空，则在S1005，通过所调用的epoll_wait函数对事件进行监听；

如果不为空，则在S1006，对通知缓存队列中的报文通知进行处理并结束本次流程；

在S1007，双栈选路模块可以根据epoll_wait函数是否有返回值来确定是否监听到了事件；

如果在epoll_wait函数的超时时间内并未监听到事件，则epoll_wait函数的返回值为0，并相应地结束本次流程；

如果监听到了事件，则在S1008，双栈选路模块可以确定第一epoll fd的状态是否发生了变化；

如果第一epoll fd的状态并未发生变化，则可以确定所监听到的事件不是用户态下的报文接收事件，在此情况下可以相应地结束本次流程；如果第一epoll fd的状态发生了变化，则可以确定所监听到的事件是用户态下的报文接收事件，于是在S1009，双栈选路模块可以接收处理报文通知队列中的报文通知；

在S1010，双栈选路模块可以确定报文通知队列中的报文通知的数量是否超出了epoll_wait函数中events列表的事件个数限制，也就是说，确定报文通知的数量是否超过了接收数量上限；

如果是，则在S1011，将超过接收上限的报文通知缓存在通知缓存队列中；如果否，则通过本次流程正常地完成了对报文接收事件的监听并相应地接收了报文通知。

通过上述实施例，使得双栈选路模块还能够在不借助额外的编码或程序的情况下，通过确定发生变化的文件描述符是否为与eventfd通知对应的文件描述符来选择将接收到的报文通知和报文数据转发至边车代理程序还是内核态协议栈，从而进一步提高了双栈选路模块以及应用适配动态链接库的代码可读性、易用性以及通用性，并且有助于程序编码的轻量化。

图11示出了实施根据本公开实施例的云计算数据交互方法的各功能模块之间的交互流程图。其中：

在S1101，边车代理程序可以在LD_PRELOAD机制的影响下，通过应用适配模块调用应用适配动态链接库中的socket类函数；

在S1102，响应于边车代理程序的调用动作和对报文的劫持，双栈选路模块也可以调用socket类函数并相应地建立用户态socket接口和内核态socket接口；

在S1103，双栈选路模块可以根据IP地址所属的IP地址段来实施双栈选路，即，选择调用用户态通信接口或内核态通信接口来对报文进行发送；

在S1104，在确定通信接口之后，双栈选路模块可以向适配通信模块发送用于建立通信链路的信令；

在S1105，适配通信模块可以将该用于建立通信链路的信令分发至协议加速进程的加速通信模块；

在S1106，加速通信模块则可以向用户态TCP/IP协议栈发送用于建立通信链路的信令，并相应地建立通信链路；

在S1107，在报文接收过程中，报文卸载技术栈可以接收报文并将报文卸载到用户空间中，之后可以将所卸载的报文传送至用户态TCP/IP协议栈处；

在S1108，用户态TCP/IP协议栈可以将报文分发至加速通信模块；

在S1109和S1110，加速通信模块可以向应用适配动态链接库的适配通信模块发送报文通知和报文数据，并且之后，在S1111，加速通信模块还可以向适配通信模块发送eventfd通知；

在S1112，在边车代理程序侧，边车代理程序可以通过应用适配模块调用应用适配动态链接库中的epoll_wait函数；

在S1113，响应于边车代理程序的调用动作和通过应用适配模块传送的信令，双栈选路模块也可以调用epoll_wait函数以对用户态事件进行监听；

在S1114，在通过epoll_wait函数监听到用户态下的报文通知事件时，双栈选路模块可以对报文通知进行接收；

在S1115，适配通信模块可以将报文通知转发给双栈选路模块；

在S1116和S1117，双栈选路模块可以将接收到的报文通知转发给应用适配模块，而应用适配模块则可以相应地将报文通知转发给边车代理程序；

在S1118，在接收到报文通知之后，边车代理程序可以获知当前存在待接收的报文数据，因此边车代理程序可以通过应用适配模块调用read类接口；

在S1119，响应于边车代理程序的调用动作和通过应用适配模块传送的信令，双栈选路模块也可以调用read类接口；

在S1120，通过调用read类接口，双栈选路模块可以从适配通信模块接收报文，并将报文拷贝到read缓存器，从而使边车代理程序能够对报文进行读取；

在S1121，当边车代理程序所服务于的微服务接收到报文并通过发送报文进行回应时，边车代理程序可以通过应用适配模块调用write类接口；

在S1122，响应于边车代理程序的调用动作和通过应用适配模块传送的信令，双栈选路模块也可以调用write类接口；

在S1123，通过调用write类接口，双栈选路模块可以将用于回应的报文数据发送至适配通信模块；

并在S1124，适配通信模块则可以将报文数据转发至协议加速进程的加速通信模块；

在S1125和S1126，加速通信模块可以将报文数据组装成相应的报文并将报文发送至用户态TCP/IP协议栈处，而用户态TCP/IP协议栈进而可以将报文发送至报文卸载技术栈处，最终由该报文卸载技术栈完成对报文的发送。

综上所述，利用本公开示例性实施方式的云计算数据交互方法，一方面，通过将各个边车代理程序在进行报文收发时所调用的TCP/IP协议由在内核态下实现转换为在用户态下实现，避免了在数据交互过程中由于多次调用内核TCP/IP协议栈而造成在内核态与用户态之间频繁切换，从而通过一种无侵入的、和应用分离的、支持双栈的用户态协议栈减少了系统对内核TCP/IP协议栈的调用，并相应地降低了CPU资源开销，因而显著降低了由边车代理程序带来的时延。另一方面，通过将报文收发过程中所调用的用户态TCP/IP协议栈和报文卸载技术栈整合为单独的协议加速进程，使得该协议加速进程占用的CPU资源可控，因而进一步降低了CPU资源的占用，而节省出的CPU资源则可以调配给边车代理程序使用，从而还能够提升边车代理程序的性能，降低处理时延。

示例性装置

在介绍了本公开示例性实施方式的云计算数据交互方法之后，接下来，参考图12对根据本公开示例性实施方式的云计算数据交互系统进行描述。其中，系统实施例部分可以继承方法实施例中的相关描述，使得系统实施例可以获得方法实施例相关具体描述的支持。

参考图12所示，该云计算数据交互系统1200可以应用于服务器或服务器集群，该服务器或服务器集群可以用于运行微服务，该云计算数据交互系统1200可以包括边车代理程序1210、应用适配动态链接库1220、以及协议加速进程1230，其中，当该云计算数据交互系统1200应用于报文发送端时：

边车代理程序1210可以用于劫持由微服务发送的报文；

应用适配动态链接库1220可以包括用户态通信接口，所述应用适配动态链接库1220可以用于被所述边车代理程序1210调用并通过所述用户态通信接口将劫持到的所述报文发送至协议加速进程1230，

所述协议加速进程1230可以包括用户态TCP/IP协议栈和报文卸载技术栈，所述协议加速进程1230可以用于通过所述用户态TCP/IP协议栈和所述报文卸载技术栈在用户态下对所述报文进行发送。

而当该云计算数据交互系统1200应用于报文接收端时：

所述边车代理程序1210可以用于在所述边车代理程序1210被调用时调用应用适配动态链接库1220，所述应用适配动态链接库1220可以包括用户态通信接口；

所述协议加速进程1230可以包括用户态TCP/IP协议栈和报文卸载技术栈，所述协议加速进程1230可以用于在所述协议加速进程1230被调用时调用所述用户态TCP/IP协议栈并且通过所述报文卸载技术栈在用户态下对报文进行接收；

所述应用适配动态链接库1220可以用于通过所述用户态通信接口从所述协议加速进程1230接收报文，并将接收到的所述报文传递至所述边车代理程序1210；

所述边车代理程序1210还用于将所述报文转发至微服务。

由于本公开实施方式的云计算数据交互系统的各个功能模块与上述方法发明实施方式中对应相同，因此在此不再赘述。

示例性设备

接下来，将对本公开的示例性实施方式的电子设备进行描述。其中，本公开的示例性实施方式的电子设备包括上述云计算数据交互系统。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施方式、完全的软件实施方式(包括固件、微代码等)，或硬件和软件方面结合的实施方式，这里可以统称为“电路”、“模块”或“系统”。

在一些可能的实施方式中，根据本公开的电子设备可以至少包括至少一个处理单元、以及至少一个存储单元。其中，所述存储单元存储有程序代码，当所述程序代码被所述处理单元执行时，使得所述处理单元执行本说明书上述“方法”部分中描述的根据本公开各种示例性实施方式的云计算数据交互方法中的步骤。例如，所述处理单元可以执行如图5所述的步骤S510至步骤S540。

下面参照图13来描述根据本公开的这种实施方式的电子设备1300。图13显示的电子设备1300仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图13所示，计算机系统1300包括中央处理单元(CPU)1301，其可以根据存储在只读存储器(ROM)1302中的程序或者从存储部分1308加载到随机访问存储器(RAM)1303中的程序而执行各种适当的动作和处理。在RAM 1303中，还存储有系统操作所需的各种程序和数据。CPU1301、ROM 1302以及RAM 1303通过总线1304彼此相连。输入/输出(I/O)接口1305也连接至总线1304。

以下部件连接至I/O接口1305：包括键盘、鼠标等的输入部分1306；包括诸如阴极射线管(CRT)显示器、液晶显示器(LCD)等以及扬声器等的输出部分1307；包括硬盘等的存储部分1308；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1309。通信部分1309经由诸如因特网的网络执行通信处理。驱动器1310也根据需要连接至I/O接口1305。可拆卸介质1311，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1310上，以便于从其上读出的计算机程序根据需要被安装入存储部分1308。

特别地，根据本公开的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分1309从网络上被下载和安装，和/或从可拆卸介质1311被安装。在该计算机程序被中央处理单元(CPU)1301执行时，执行本申请的方法和系统中限定的各种功能。

示例性程序产品

在一些可能的实施方式中，本公开的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在终端设备上运行时，所述程序代码用于使所述终端设备执行本说明书上述“方法”部分中描述的根据本公开各种示例性实施方式的云计算数据交互方法中的步骤，例如，所述终端设备可以执行如图5所述的步骤S510至步骤S540。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光盘、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。另外，随着技术的发展，可读存储介质也应进行相应解读。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了云计算数据交互系统的若干模块或子模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块的特征和功能可以在一个模块中具体化。反之，上文描述的一个模块的特征和功能可以进一步划分为由多个模块来具体化。

此外，尽管在附图中以特定顺序描述了本公开方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

虽然已经参考若干具体实施方式描述了本公开的精神和原理，但是应该理解，本公开并不限于所公开的具体实施方式，对各方面的划分也不意味着这些方面中的特征不能组合以进行受益，这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。