CN113973052A - 云网络系统、数据传输方法、计算节点及存储介质 - Google Patents

Abstract

本申请实施例提供一种云网络系统、数据传输方法、计算节点及存储介质。在本申请实施例中，在云网络系统中的计算节点上部署可为上层应用提供数据面加速服务的云原生基础组件，借助于该云原生基础组件一方面可解耦上层应用对硬件资源的直接依赖，与云网络系统采用的虚拟化技术相适配，另一方面可在数据面上旁路计算节点的内核协议栈，从而为云网络系统中的上层应用提供数据面加速服务，解决云网络系统面临的数据面加速问题，而且该方案的实施对上层应用的开发和部署几乎没影响，还可以降低用户对上层应用的开发和部署难度，而且可以做到任何计算节点无差异部署，具有较强的实施灵活性。

Description

云网络系统、数据传输方法、计算节点及存储介质

技术领域

本申请涉及云网络技术领域，尤其涉及一种云网络系统、数据传输方法、计算节点及存储介质。

背景技术

随着云计算技术的发展，各种云网络系统以及云原生应用不断涌现。云原生应用也就是面向“云”而设计的应用，在使用云原生技术后，开发者无需考虑底层的技术实现，可以充分发挥云网络的资源弹性和分布式优势，实现快速部署、按需伸缩、不停机交付等。

在实际应用中，一些云原生应用在数据面上对数据吞吐率、传输延时都有很高要求。例如，随着5G网络的出现，通信技术(Communications Technology，CT)对基础网络架构的云化提出了更高的要求，为了满足对基础网络架构的云化需求，提出了CT上云的概念，即采用云原生技术对CT领域中的应用进行开发并部署到云网络中。这些上云的CT应用通常对数据吞吐率、传输延时都有很高要求，这就需要一种数据面加速方案。

在现有技术中，存在一些直接在用户态进行数据包处理，通过避免在用户态和内核态之间来回切换实现加速的方案，例如数据平面开发套件(Data Plane DevelopmentKit，DPDK)。但是，这些加速方案需要上层应用跳过系统内核协议栈的处理直接访问物理网卡、内存等硬件资源，这与云网络使用虚拟化技术屏蔽上层应用对物理资源的依赖的特性是相冲突的，也就是说现有针对数据面的加速方案无法适用于云网络系统。目前，行业内还不存在适用于云网络的数据面加速解决方案。

发明内容

本申请的多个方面提供一种云网络系统、数据传输方法、计算节点及存储介质，用以在云网络中提供实现数据面加速服务的云原生基础组件，解决云网络面临的数据面加速问题。

本申请实施例提供一种云网络系统，包括：多个计算节点，所述多个计算节点采用虚拟化技术提供虚拟化计算环境，所述虚拟化计算环境用于承载上层应用；所述多个计算节点上还部署有用于为所述上层应用提供数据面加速服务的云原生基础组件；所述云原生基础组件，用于响应来自数据面的数据传输请求，旁路其所在计算节点的内核协议栈，调用所述计算节点的硬件资源为与所述数据传输请求对应的上层应用提供数据传输服务，所述硬件资源至少包括与所述云原生基础组件适配的第一物理网卡。

本申请实施例还提供一种数据传输方法，应用于云网络系统中的计算节点，所述计算节点上部署有用于为上层应用提供数据面加速服务的云原生基础组件，所述方法包括：所述云原生基础组件响应来自数据面的数据传输请求，旁路所述计算节点的内核协议栈，调用所述计算节点的硬件资源为与所述数据传输请求对应的上层应用提供数据传输服务，所述硬件资源至少包括与所述云原生基础组件适配的第一物理网卡。

本申请实施例还提供一种直播数据传输方法，应用于云网络系统中的计算节点，所述计算节点上部署有用于为云上直播应用提供数据面加速服务的云原生基础组件，所述方法包括：所述云原生基础组件响应来自直播端的直播传输请求，所述直播传输请求指向所述云上直播应用；旁路所述计算节点的内核协议栈，调用所述计算节点的硬件资源为所述云上直播应用提供直播数据传输服务，所述硬件资源至少包括与所述云原生基础组件适配的第一物理网卡。

本申请实施例还提供一种计算节点，应用于云网络系统中，所述计算节点包括：存储器和处理器；所述存储器中用于存储虚拟化程序；所述处理器与所述存储器耦合，用于执行所述虚拟化程序，以用于：采用虚拟化技术在所述计算节点上提供虚拟化计算环境，所述虚拟化计算环境用于承载上层应用；所述存储器中还用于存储为所述上层应用提供数据面加速服务的云原生基础组件，所述处理器还用于执行所述云原生基础组件，以用于执行本申请实施例提供的数据传输方法中的步骤。

本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当所述计算机程序被处理器执行时，致使所述处理器实现本申请实施例提供的数据传输方法中的步骤。

在本申请实施例中，在云网络系统中的计算节点上部署可为上层应用提供数据面加速服务的云原生基础组件，借助于该云原生基础组件一方面可解耦上层应用对硬件资源的直接依赖，与云网络系统采用的虚拟化技术相适配，另一方面可在数据面上旁路计算节点的内核协议栈，从而为云网络系统中的上层应用提供数据面加速服务，解决云网络系统面临的数据面加速问题，而且该方案的实施对上层应用的开发和部署几乎没影响，还可以降低用户对上层应用的开发和部署难度，而且可以做到任何计算节点无差异部署，具有较强的实施灵活性。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请示例性实施例提供的一种云网络系统的结构示意图；

图2为本申请示例性实施例提供的另一种云网络系统的结构示意图；

图3为本申请示例性实施例提供的云网络系统中基于云原生组件的数据面加速路径示意图；

图4a为本申请示例性实施例提供的一种数据传输方法的流程示意图；

图4b为本申请示例性实施例提供的一种直播数据传输方法的流程示意图；

图5为本申请示例性实施例提供的一种云原生基础组件的结构示意图；

图6为本申请示例性实施例提供的一种计算节点的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

针对现有云网络系统面临的数据面加速问题，在本申请实施例中，在云网络系统中的计算节点上部署可为上层应用提供数据面加速服务的云原生基础组件，借助于该云原生基础组件一方面可解耦上层应用对硬件资源的直接依赖，与云网络系统采用的虚拟化技术相适配，另一方面可在数据面上旁路计算节点的内核协议栈，从而为云网络系统中的上层应用提供数据面加速服务，解决云网络系统面临的数据面加速问题，而且该方案的实施对上层应用的开发和部署几乎没影响，还可以降低用户对上层应用的开发和部署难度，而且可以做到任何计算节点无差异部署，具有较强的实施灵活性。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1为本申请示例性实施例提供的一种云网络系统的结构示意图。如图1所示，该云网络系统100包括：多个计算节点10，多个计算节点10之间网络互联。其中，计算节点10是云网络系统100中具有一定计算能力的资源设备，例如可以是服务器、计算机设备、移动终端等。

在本实施例中，并不限定云网络系统100的实现形式，例如可以是中心云系统，如图1所示。进一步，在云网络系统100是中心云系统的情况下，云网络系统100可以实现为专有云系统或公有云系统。在云网络系统100是中心云系统的情况下，中心云系统可以包括至少一个云计算数据中心和/或传统数据中心，所述多个计算节点10分布部署在至少一个云计算数据中心和/或传统数据中心中。

除可以实现为中心云系统之外，本实施例的云网络系统100还可以实现为边缘云系统，如图2所示。如图2所示，在云网络系统100实现为边缘云系统的情况下，该系统100包括多个边缘云节点20，多个边缘云节点20之间可以网络连接。本实施例的边缘云系统是基于云计算技术和边缘计算的能力，构筑在边缘基础设施之上的云计算平台，是一种靠近边缘位置的具备计算、网络、存储以及安全等能力的网络系统。边缘云是个相对概念，边缘云是指相对靠近终端的云计算平台，这里的终端是指云计算服务的需求端，例如可以是互联网中的终端或者用户端，或者物联网中的终端或用户端。或者说，本实施例的边缘云系统与中心云或者传统的云计算平台相区别，中心云或者传统的云计算平台可以包括资源规模化且位置集中的数据中心，而本实施例的边缘云系统包括边缘云节点20，这些边缘云节点20分散在不同区域位置，覆盖的网络范围更广泛，也因此具备距离终端更近的特性，单个边缘云节点20的资源规模较小，但是边缘云节点20的数量相对较多。另外，本实施例的边缘云节点20可以全部由同一互联网服务提供商(Internet Service Provider，ISP)部署，也可以由不同ISP部署实现，对此不做限定。

在本实施例中，每个边缘云节点20可实现为位于边缘的互联网数据中心(Internet Data Center，IDC)，即一个边缘IDC即为本申请实施例中的一个边缘云节点20；或者，边缘云节点20可实现为位于边缘的机房，即一个机房即为本申请实施例中的一个边缘云节点20。在此说明，不同边缘云节点20的位置、能力以及包含的基础设施可以相同，也可以不相同。如图2所示，本实施例的多个计算节点10分布部署在这些边缘云节点20中。

无论云网络系统100实现为图1所示的中心云系统还是实现为图2所示的边缘云系统，该云网络系统100除了包括计算节点10之外，还包括中心管控节点11，如图1和图2所示。中心管控节点11可以作为是应用提供方与云网络系统100之间的交互接口，可接收应用提供方的应用部署需求，根据该应用部署需求对多个计算节点10进行资源调度，即根据应用提供方的应用部署需求在计算节点10上部署相应上层应用。其中，服务提供方是边缘云系统100的用户，是需要在边缘云系统100中部署服务的一方，可选地，应用提供方可以是一些企业或组织，也可以是个人。可选地，中心管控节点11可以对外提供应用部署需求的提交入口，该提交入口可以是web页面、应用页面或命令窗等；该提交入口的作用是供应用提供方向中心管控节点11提交自己的应用部署需求。在云网络系统100实现为边缘云系统的情况下，中心管控节点11还可以对多个边缘云节点20进行各种管控和资源调度，可选地，中心管控节点11可以部署在一个或多个云计算数据中心中，或者，可以部署在一个或多个传统数据中心中；当然，中心管控节点11也可以部署在边缘云系统中，例如可以部署在一个、两个或两个以上的边缘云节点20中，本实施例对此不做限定。当然，中心管控节点11的功能并不限于此。

无论云网络系统100实现为哪种形式，在本实施例中，多个计算节点10可采用虚拟化技术提供虚拟化计算环境，这些虚拟化计算环境可用于承载上层应用；其中，计算节点10是虚拟化计算环境的宿主机。在一可选实施例中，每个计算节点10可以采用容器(container)技术提供容器环境，上层应用被部署在容器中；其中，容器会共享其所在计算节点10的OS，但具有隔离的资源结构，具有较高的数据安全性。本实施例的容器可以采用但不限于docker技术实现，采用docker技术部署的容器可称为docker容器。在一可选实施例中，可以采用容器组(pod)对容器进行组织管理，则上层应用被部署在pod中。或者，在另一可选实施例中，每个计算节点10可以采用虚拟机技术提供虚拟机环境，上层应用被部署在虚拟机中，该虚拟机具有独立的OS。

在本实施例中，上层应用可以是基于云原生技术开发的云原生应用。从应用场景来看，本实施例中的上层应用可以是5G上云场景中的云原生应用，还可以是内容分发网络(Content Delivery Network，CDN)、电商、游戏、音视频、物联网、物流、工业大脑、城市大脑等其它应用场景中的云原生应用。从应用内容来看，本实施例中的上层应用可以是在线直播应用、在线分析应用、负载均衡应用、实时公交应用等。在本实施例中，上层应用具有跨计算节点进行数据传输的需求，例如，可以接收部署在其它计算节点上的上层应用发送的数据进行处理并将处理后的数据转发出去，也可以自身产生数据并将产生的数据发送给其它计算节点上的上层应用，或者也可以接收部署在其它计算节点上的上层应用发送的数据。

相对于控制面，数据面对数据吞吐率、时延等具有较高的要求，为了满足这些要求，本申请实施例提出了将数据面加速服务作为云网络系统100中的“底座”实现，针对云网络系统中的上层应用提供数据面加速服务，以提高云网络系统中上层应用(或云原生应用)在数据面上进行数据传输的高效性。具体地，将数据面加速服务设计成云网络系统100支持的云原生基础组件12，并将该云原生基础组件12部署到云网络系统100中的计算节点10上，如图1和图2所示；由该云原生基础组件12响应来自数据面的数据传输请求，旁路计算节点10的内核协议栈，调用计算节点10的硬件资源为与该数据传输请求对应的上层应用提供数据传输服务。这里的硬件资源至少包括与云原生基础组件12适配的第一物理网卡、内存和处理器(CPU)；第一物理网卡、内存和处理器相互配合，可在旁路内核协议栈的情况下为上层应用提供数据传输服务。其中，旁路内核协议栈是指不经过内核协议栈，即直接跨过内核协议栈对数据报文进行收发处理，数据报文可以直接在第一物理网卡与用户空间之间进行传输，减少了先从物理网卡到内核空间再从内核空间到用户空间的内存拷贝过程，有利于提高数据传输效率。

本实施例的数据传输服务主要是指针对数据面报文提供的传输服务，尤其是指针对数据报文的传输服务。其中，与数据报文对应的是协议报文，协议报文主要是指带有协议字段的报文，例如可以是各种网络协议报文，例如路由协议报文、TCP协议报文，也可以是上层应用产生的带协议字段的报文，协议报文的处理依赖于相应协议栈。相应地，数据报文属于上层应用产生的用户报文。云原生基础组件12可以配置第一物理网卡针对数据报文的收发逻辑，以使第一物理网卡在接收到数据报文的情况下，可配合云原生基础组件12在旁路内核协议栈的情况下，由用户空间直接控制第一物理网卡将数据报文上报给上层应用，或者将数据报文再次转发出去，而不用将数据报文送入内核协议栈中进行处理，通过减少中断次数和内存读写次数等提高数据报文的处理效率。

在本实施例中，借助于云原生基础组件12，一方面可解耦上层应用对硬件资源的直接依赖，即上层应用不再直接与硬件资源进行交互，而是由云原生基础组件12与硬件资源进行交互，这点与虚拟化技术会屏蔽上层应用对物理资源的依赖的特性相适配；另一方面，通过在数据面上旁路计算节点的内核协议栈，由用户空间直接控制第一物理网卡进行数据报文收发，可减少因将数据报文送入内核协议栈产生的中断次数，减少数据报文从内核态向用户态拷贝的次数，从而为云网络系统中的上层应用提供数据面加速服务，解决云网络系统面临的数据面加速问题。另外，在计算节点10中部署云原生基础组件12，对上层应用的开发和部署几乎没影响，还可以降低用户对上层应用的开发和部署难度，而且可以做到任何计算节点无差异部署，具有较强的实施灵活性。

进一步，如图3所示，在云网络系统100中，以两个计算节点10为例，每个计算节点10上部署有若干个pod，这些pod中承载有上层应用，这两个计算节点10上的上层应用之间可以进行数据传输。进一步，如图3所示，在每个计算节点12上还部署有用于提供数据面加速服务的云原生基础组件12，除此之外，还包括OS中的内核协议栈；所述上层应用之间进行数据传输时，可使用云原生组件12提供的数据面加速服务，其中，数据面加速服务的加速路径如图3中的带箭头的实线所示，即对每个上层应用而言，可以通过其所在计算节点10上的云原生基础组件12以及与云原生基础组件12适配的第一物理网卡与另一计算节点10上的上层应用进行数据传输，在该传输过程中旁路了计算节点OS中的内核协议栈，即数据不需要经过内核协议栈的处理，这可以减少中断次数和内存拷贝次数，进而有利于提高数据处理的高效性。

进一步可选地，在一些特殊情况下，数据面上也可能有一些协议报文，这些数据面上的协议报文需要依赖对应的协议栈进行处理。在一可选实施例中，这些数据面上的协议报文是与上层应用相关的协议报文，则本实施例的云原生基础组件12还可以提供用户态协议栈，该用户态协议栈用于对数据面的协议报文进行处理，即第一物理网卡还可以接收协议报文并在接收到协议报文的情况下将协议报文上报给云原生基础组件12，由云原生基础组件12在旁路内核协议栈的情况下基于该用户态协议栈对数据面的协议报文进行相应协议栈的处理。但是，需要说明的是，对数据面上的协议报文进行处理的方式并不限于由云原生基础组件12实现用户态协议栈的方式。

可选地，在另一可选实施例中，如图3中带箭头的点虚线所示，本实施例的云原生基础组件12还可以与内核协议栈进行交互，借助于内些协议栈对一些协议报文进行协议栈处理，具体地，云原生基础组件12可以将协议报文提供给其所在计算节点上的OS，由OS利用内核协议栈对协议报文进行协议栈处理后提供给上层应用。其中，可由OS利用内核协议栈进行处理的协议报文可以是数据面的协议报文，也可以是控制面的协议报文。其中，控制面的协议报文也可以称为控制面消息，这些控制面消息需要基于内核协议栈进行处理。进一步可选地，云原生基础组件12可以采用内核接口机制或虚拟网卡设备与内核协议栈进行交互。其中，内核接口机制或虚拟网卡设备可以让数据报文重入内核协议栈。

需要说明的是，在云原生基础组件12可以与内核协议栈进行交互的实施例中，计算节点10可以仅包括一张物理网卡，即第一物理网卡；基于此，云原生基础组件12还可以配置第一物理网卡针对协议报文的转发逻辑，以使第一物理网卡将接收到的协议报文上报给云原生基础组件12。相应地，云原生基础组件12在接收到第一物理网卡上报的协议报文时，基于内核接口机制或虚拟网卡设备，将协议报文传输给计算节点的OS，以供该OS基于内核协议栈对协议报文进行协议栈处理后提供给上层应用。

当然，计算节点10也可以采用两张物理网卡，即包括第一物理网卡和第二物理网卡；第一物理网卡负责数据报文的收发，与第一物理网卡相对应，第二物理网卡是与计算节点10的OS适配的物理网卡，即第二物理网卡的驱动程序属于OS，具体用于负责与上层应用对应的协议报文的收发；对OS来说，可以在第二物理网卡接收到的协议报文的情况下，利用内核协议栈对协议报文进行协议栈处理后提供给上层应用。其中，协议报文由第二物理网卡接收并经内核协议栈处理到达上层应用的路径如图3中带箭头的点划线所示。

在本申请实施例中，并不限定云原生基础组件12的实现方式。在一可选实施例中，如图1-图3所示，云原生基础组件12包括：第一组件121和第二组件122；其中，第一组件121集成在云原生基础组件12所在计算节点的OS中，用于提供访问该计算节点的硬件资源(如与云原生基础组件12适配的第一物理网卡、内存和处理器)所需的库函数；第二组件122部署在云原生基础组件12所在计算节点上依赖该计算节点的OS的目标计算环境中，用于面向部署在该计算节点提供的虚拟化计算环境中的上层应用提供服务接口和对库函数的调用功能，以旁路该计算节点OS中的内核协议栈从而为上层应用提供数据面加速服务。其中，第二组件通过提供服务接口可以将云原生基础组件12提供的数据面加速服务暴露给上层应用，使得上层应用可以使用数据面加速服务；第二组件对库函数的调用为了对第一物理网卡进行驱动，以便于在第一物理网卡配合下实现数据面加速服务。

在上述实施例中，第一组件121集成在计算节点的OS中，为了便于第二组件122对第一组件121提供的库函数进行调用，第二组件122可以部署在依赖该计算节点的OS的计算环境中，称为目标计算环境。在一可选实施例中，计算节点采用容器这种虚拟化技术，那么所实现的虚拟化计算环境是采用容器技术实现的容器，在该情况下，可以将第二组件122部署在计算节点上的某个容器中，例如部署在某个pod中，也就是说，承载第二组件122的目标计算环境可以是计算节点提供的容器。在另一可选实施例中，计算节点采用虚拟机这种虚拟化技术，那么所实现的虚拟化计算环境是采用虚拟机技术实现的虚拟机，在该情况下，由于虚拟机具有独立的OS，所以第二组件122不能部署在虚拟机中，当可以将第二组件122直接部署在计算节点上未经虚拟化的计算环境中，也就是说，承载第二组件122的目标计算环境可以是计算节点提供的非虚拟化计算环境，该非虚拟化计算环境也可以称为计算节点基于其硬件资源所提供的物理计算环境。

在本申请实施例中，并不限定第一组件121的实现方式，可以是自研组件，也可以采用已有的数据面加速组件，例如第一组件可以采用已有的DPDK或XDP(英文全称为：eXpress Data Path)，即可以将DPDK或XDP集成到计算节点的OS中，并且通过第二组件122以服务接口的方式将数据面加速服务暴露给云网络系统中的上层应用(即云原生应用)，上层应用可通过第二组件提供的服务接口配置数据报文的转发策略达到直接转发，或者通过服务接口直接从第一物理网卡获取数据报文的目的。

在本申请实施例中，对上层应用来说通过数据面加速服务进行数据传输具有以下三种场景，下面分别进行详细说明：

1、数据转发场景：上层应用接收来自其它计算节点上的上层应用或其它设备的数据报文，对数据报文进行一定处理后再将处理后的数据报文转发出去。对于数据转发场景，数据面的数据传输请求具体为数据转发请求，在该情况下，第二组件具体用于基于服务接口和库函数控制第一物理网卡为上层应用进行数据报文转发。

进一步，第二组件基于服务接口和库函数控制第一物理网卡为上层应用进行数据报文转发，可以采用以下三种方式中的任一方式：

方式A1：第二组件预先在本地维护上层应用通过服务接口下发的用于数据转发的流表，并基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡将接收到的数据报文上报给第二组件；以及在接收到第一物理网卡上报的数据报文时，基于本地维护的流表对该数据报文进行处理并通过第一物理网卡将处理后的数据报文转发出去。

在方式A1中，第二组件具有维护流表和对数据报文进行处理的指定能力，基于此，上层应用可以通过第二组件对外提供的服务接口将用于数据转发的流表下发给第二组件；第二组件预先在本地维度该流表，以便基于该流表对数据报文进行相应转发处理。所述流表至少包括与Qos相关的规则表。进一步，第二组件预先基于库函数配置第一物理网卡针对数据报文的转发逻辑，例如可以通过库函数对第一物理网卡上用于控制该网卡行为的寄存器进行配置，使得经过配置后的寄存器能够控制该网卡将接收到的数据报文上报给第二组件并且能够将第二组件下发的数据报文转发出去。除此之外，还可以配置第一物理网卡收发数据的队列以及对数据报文的校验方式等。在此基础上，第一物理网卡在接收到报文的情况下，可以根据配置信息识别是否为数据报文，在确定接收到数据报文的情况下，将数据报文上报给第二组件；第二组件基于本地维护的流表对数据报文进行处理，该处理具体可视流表中约定的处理动作而定，例如可以是转发、丢弃、排队等。在基于流表对数据报文进行处理后，第二组件将处理后的数据报文提供给第一物理网卡，第一物理网络将处理后的数据报文转发出去。

在方式A1中，上层应用通过在第二组件本地配置流表，使得数据报文直接在第二组件上完成处理，无需到达上层应用，有利于进一步减少数据报文的处理延时，提高处理效率。

在此说明，在方式A1中，对第一物理网卡的能力不做限定，只要具有数据转发功能且与云原生基础组件12适配即可。以DPDK或XDP为例，第一物理网卡可以是DPDK或XDP支持的网卡列表中的网卡即可。

方式A2：第二组件预先将上层应用通过服务接口下发的用于数据转发的流表配置到第一物理网卡中，并基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡根据该流表对接收到的数据报文进行转发处理。

在方式A2中，第一物理网卡具有维护流表和对数据报文进行处理的指定能力，而且具有数据转发功能且与云原生基础组件12适配，例如可以采用智能网卡。基于此，上层应用可以通过第二组件对外提供的服务接口将用于数据转发的流表下发给第二组件；第二组件将该流表配置到第一物理网卡中，以便第一物理网卡基于该流表对数据报文进行相应转发处理。所述流表至少包括与Qos相关的规则表。进一步，第二组件预先基于库函数配置第一物理网卡针对数据报文的转发逻辑，例如可以通过库函数对第一物理网卡上用于控制该网卡行为的寄存器进行配置，使得经过配置后的寄存器能够控制该网卡基于流表对接收到的数据报文进行转发处理并将处理后的数据报文转发出去。除此之外，还可以配置第一物理网卡收发数据的队列以及对数据报文的校验方式等。在此基础上，第一物理网卡在接收到报文的情况下，可以根据配置信息(如报文的IP地址)识别是否为数据报文，在确定接收到数据报文的情况下，基于本地维护的流表对数据报文进行处理，该处理具体可视流表中约定的处理动作而定，例如可以是转发、丢弃、排队等。在基于流表对数据报文进行处理后，第一物理网络直接将处理后的数据报文转发出去。

在方式A2中，上层应用通过第二组件在第一物理网卡上配置流表，使得数据报文直接在第一物理网卡上完成处理，无需到达上层应用，有利于进一步减少数据报文的处理延时，提高处理效率。

方式A3：第二组件预先基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡将接收到的数据报文上报给所述第二组件；以及在接收到第一物理网卡上报的数据报文时，基于服务接口将数据报文上报给上层应用进行处理并接收上层应用处理后的数据报文，通过第一物理网卡将处理后的数据报文转发出去。

在方式A3中，考虑到复杂转发情况或者需要对数据报文进行更改(例如修改指定字段信息)的情况，为了保证对数据报文进行准确处理，允许将数据报文上报至上层应用，由上层应用对数据报文进行转发处理。基于此，上层应用可以在本地维护用于数据转发的流表；第二组件预先基于库函数配置第一物理网卡针对数据报文的转发逻辑，例如可以通过库函数对第一物理网卡上用于控制该网卡行为的寄存器进行配置，使得经过配置后的寄存器能够控制该网卡将接收到的数据报文上报给第二组件并且能够将第二组件下发的数据报文转发出去。除此之外，还可以配置第一物理网卡收发数据的队列以及对数据报文的校验方式等。在此基础上，第一物理网卡在接收到报文的情况下，可以根据配置信息(如报文的IP地址)识别是否为数据报文，在确定接收到数据报文的情况下，将数据报文上报给第二组件；第二组件通过服务接口将数据报文上报给上层应用进行处理，并接收上层应用处理后的数据报文，将该处理后的数据报文通过第一物理网卡转发出去。其中，上层应用可以根据应用需求灵活地对数据报文进行处理，例如修改指定字段、排队、校验等。

进一步可选地，第二组件还可以读取第一物理网卡上的寄存器，获取第一物理网卡接收报文的速率、丢包情况等信息，连同数据报文一并上报给上层应用，供上层应用参考这些信息对数据报文进行处理。

在方式A3中，可选地，第二组件基于服务接口将数据报文上报给上层应用时，可采用消息队列方式将数据报文上报给上层应用并采用消息队列的方式接收上层应用下发的处理后的数据报文。如图3所示，在上层应用与第二组件之间存在消息队列(MSGQ)，具体地，第二组件将需要上报的数据报文写入消息队列中，上层应用通过服务接口访问第二组件的消息队列，从中读取数据报文；在上层应用对数据报文进行处理后，通过服务接口访问消息队列以将处理后的数据报文写入消息队列中，第二组件从消息队列中读取处理后的数据报文。

在此说明，在方式A3中，对第一物理网卡的能力不做限定，只要具有数据转发功能且与云原生基础组件12适配即可。以DPDK或XDP为例，第一物理网卡可以是DPDK或XDP支持的网卡列表中的网卡即可。

在上述方式A1-A3中，第一物理网卡接收到的数据来自于另一个计算节点，也可以来自于云网络系统之外的其它设备，例如在上层应用是基于移动通信网络(如5G网络)的云原生应用的情况下，所述其它设备可以是移动通信网络中的基站或核心网设备或者用户终端等。例如，在线直播场景中，上层应用可以是内容分发网络(Content Delivery Network，CDN)应用，负责接收其上游计算节点上的CDN应用或直播端传输来的直播视频流，并将该直播视频流转发给其下游计算节点上的CDN应用，依次类推，直至直播视频流到达用户终端。对于任一计算节点上的CDN应用，可以采用上述方式A1-A3中的任一种方式来接收直播视频流。

进一步，在确定使用上述三种方式中的哪种方式时，可由上层应用根据第一物理网卡和云原生基础组件的能力信息而定。基于此，第二组件还用于获取第一物理网卡和其所属云原生基础组件的能力信息，并将这些能力信息上报给上层应用，以供上层应用根据这些能力信息确定流表的配置信息，该配置信息中包括流表的配置位置或者为第二组件或者为第一物理网卡；之后，第二组件可接收上层应用下发的流表的配置信息，根据上层应用下发的所述配置信息中的配置位置，确定需要将流表配置在本地或第一物理网卡上，进而将流表配置在本地或第一物理网卡上。

或者

在另一可选实施例中，在确定使用上述三种方式中的哪种方式时，可由第二组件根据第一物理网卡的能力信息而定。在本实施例中，默认第二组件具有维护流表和基于流表对数据报文进行转发处理的指定能力。基于此，第二组件还用于：获取第一物理网卡的能力信息，并根据第一物理网卡的能力信息确定第一物理网卡是否具备基于流表对数据报文进行转发处理的指定能力；在根据第一物理网卡的能力信息确定第一物理网卡具备指定能力的情况下，确定可以将该流表配置到第一物理网卡中，并在接收到上层应用通过服务接口下发的流表后将该流表配置到第一物理网卡中；或者，在根据第一物理网卡的能力信息确定第一物理网卡不具备指定能力的情况下，确定需要在本地维护流表，并在接收到上层应用通过服务接口下发的流表后将该流表维护在本地。

2、数据发送场景：上层应用作为端设备产生数据报文，需要将数据报文发送给其它计算节点上的上层应用或其它设备。对于数据发送场景，数据面的数据传输请求具体为数据发送请求，在该情况下，第二组件具体用于基于服务接口和库函数控制第一物理网卡将上层应用的数据报文发送出去。例如，在上层应用是基于移动通信网络(如5G网络)的云原生应用的情况下，所述其它设备可以是移动通信网络中的基站或核心网设备或者用户终端等。

进一步，第二组件基于服务接口和库函数控制第一物理网卡将上层应用的数据报文发送出去，包括：第二组件预先基于库函数配置第一物理网卡针对数据报文的发送逻辑，以使第一物理网卡在接收到第二组件发送的数据报文时将该数据报文发送出去；基于此，上层应用产生待发送的数据报文之后，可以通过服务接口将数据报文下发给第二组件，第二组件将数据报文提供给第一物理网卡，第一物理网卡将第二组件提供的数据报文发送出去。

可选地，上层应用基于服务接口将数据报文下发给第二组件时，可采用消息队列方式将数据报文下发给第二组件。如图3所示，在上层应用与第二组件之间存在消息队列(MSGQ)，具体地，上层应用通过服务接口访问消息队列，以将数据报文写入消息队列中，第二组件从消息队列中读取数据报文并提供给第一物理网卡。

3、数据接收场景：上层应用作为端设备需要接收由其它上层应用或其它设备产生并发送过来的数据报文。对于数据接收场景，数据面的数据传输请求具体为数据接收请求，在该情况下，第二组件具体用于基于服务接口和库函数控制第一物理网卡为上层应用提供数据接收服务，即将接收到的来自其它上层应用的数据报文提供给上层应用。例如，在上层应用是基于移动通信网络(如5G网络)的云原生应用的情况下，所述其它设备可以是移动通信网络中的基站或核心网设备或者用户终端等。

进一步，第二组件基于服务接口和库函数控制第一物理网卡为上层应用提供数据接收服务，包括：第二组件预先基于库函数配置第一物理网卡针对数据报文的接收逻辑，以使第一物理网卡在接收到其它计算节点发给其所在计算节点上的上层应用的数据报文时将该数据报文上报给第二组件，由第二组件基于服务接口提供给上层应用；基于此，第一物理网卡在接收到数据报文时，识别该数据报文的目的IP地址是否指向其所在计算节点上的上层应用；若是，则将该数据报文上报给第二组件；第二组件基于服务接口将数据报文上报给上层应用，上层应用接收到数据报文之后基于该数据报文进行后续应用处理。

可选地，第二组件基于服务接口将数据报文上报给上层应用时，可采用消息队列方式将数据报文上报给上层应用。如图3所示，在上层应用与第二组件之间存在消息队列(MSGQ)，具体地，第二组件将需要上报的数据报文写入消息队列中，上层应用通过服务接口访问第二组件的消息队列，从中读取数据报文。

需要说明的是，本申请的云网络系统中除了涉及对数据报文的处理之外，还会涉及协议报文的处理，针对协议报文的处理，本申请实施例提供以下两种方式：

方式B1：第一物理网卡同时负责数据报文和协议报文的收发处理。基于此，第二组件还用于基于库函数配置第一物理网卡针对协议报文的转发逻辑，以使第一物理网卡将接收到的协议报文上报给第二组件；以及第二组件在接收到第一物理网卡上报的协议报文时，基于内核接口机制或虚拟网卡设备，将协议报文传输给云原生基础组件所在计算节点的OS，以供该OS基于其内核协议栈对该协议报文进行协议栈处理后提供给上层应用。

进一步可选地，在第一组件采用DPDK或XDP的情况下，内核接口机制可以是KNI(英文全称为：Kernel Interface)，采用KNI可以让数据报文重入内核协议栈；或者，也可以通过创建虚拟网卡设备的方式让数据报文重入内核协议栈，虚拟网卡设备可以是TUN或TAP设备。关于KNI、TUN或TAP设备的相关描述可参见现有技术，在本申请实施例中不做详述。

方式B2：云原生基础组件所在的计算节点还包括：与OS适配的第二物理网卡，第二物理网卡用于负责与上层应用对应的协议报文的转发。基于此，第二物理网卡会接收协议报文，并将协议报文给到其所在计算节点的OS；该OS还用于在第二物理网卡接收到的协议报文的情况下，利用其内核协议栈对该协议报文进行协议栈处理后提供给上层应用。例如，基于内核协议栈对接收到的协议报文依次进行数据链路层、网络层和传输层的解封装处理，之后通过套接字(socket)方式将TCP或UDP报文提供给上层应用。相应地，在计算节点采用两张物理网卡的情况下，上层应用产生的协议报文，可以通过socket方式提供给内核协议栈，在内核协议栈中依次经传输层、网络层和数据链路层的封装处理，之后给到第二物理网卡，由第二物理网卡将封装好的协议报文转发出去。

在本申请实施例中，在云网络系统中的计算节点上部署可为上层应用提供数据面加速服务的云原生基础组件，借助于该云原生基础组件一方面可解耦上层应用对硬件资源的直接依赖，与云网络系统采用的虚拟化技术相适配，另一方面可在数据面上旁路计算节点的内核协议栈，从而为云网络系统中的上层应用提供数据面加速服务，解决云网络系统面临的数据面加速问题，而且该方案的实施对上层应用的开发和部署几乎没影响，不再依赖上层应用自身的数据面开发，还可以降低用户对上层应用的开发和部署难度，而且可以做到任何计算节点无差异部署，具有较强的实施灵活性。

除上述系统实施例之外，本申请实施例还提供一种数据传输方法，该方法可应用于云网络系统中的计算节点，该计算节点可采用虚拟化技术提供虚拟化计算环境，虚拟化计算环境可以是一个或多个，这些虚拟化计算环境用于承载上层应用；另外，该计算节点上还部署有用于为上层应用提供数据面加速服务的云原生基础组件。本实施例提供的数据传输方法主要是基于该云原生基础组件实现的，如图4a所示，该方法包括：

401、云原生基础组件响应来自数据面的数据传输请求，该数据传输请求指向上层应用。

402、旁路计算节点的内核协议栈，调用该计算节点的硬件资源为与数据传输请求对应的上层应用提供数据传输服务，所述硬件资源至少包括与云原生基础组件适配的第一物理网卡。

在一可选实施例中，云原生基础组件包括第一组件和第二组件；第一组件集成在云原生基础组件所在计算节点的OS中，用于提供访问上述硬件资源所需的库函数；第二组件部署在云原生基础组件所在计算节点上依赖该计算节点的OS的目标计算环境中，用于面向上层应用提供服务接口和对库函数的调用功能。基于此，在上述数据传输请求为数据转发请求的情况下，调用计算节点的硬件资源为与数据传输请求对应的上层应用提供数据传输服务，包括：基于服务接口和库函数控制第一物理网卡为上层应用进行数据报文转发。

进一步可选地，基于服务接口和库函数控制第一物理网卡为上层应用进行数据报文转发，包括以下任一方式：

预先在本地维护上层应用通过服务接口下发的用于数据转发的流表，并基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡将接收到的数据报文上报给第二组件；以及在接收到第一物理网卡上报的数据报文时，基于流表对数据报文进行处理并通过第一物理网卡将处理后的数据报文转发出去；

或者，

预先将上层应用通过服务接口下发的用于数据转发的流表配置到第一物理网卡中，并基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡根据流表对接收到的数据报文进行转发处理；

或者，

预先基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡将接收到的数据报文上报给第二组件；以及在接收到第一物理网卡上报的数据报文时，基于服务接口将数据报文上报给上层应用进行处理并接收上层应用处理后的数据报文，通过第一物理网卡将处理后的数据报文转发出去。

在一可选实施例中，本实施例提供的方法还包括：获取第一物理网卡和云原生基础组件的能力信息，并上报给上层应用，以供上层应用确定流表的配置信息，配置信息包括流表的配置位置为第二组件或第一物理网卡；以及根据上层应用下发的配置信息中的配置位置，确定将流表配置在本地或第一物理网卡上；或者，获取第一物理网卡的能力信息，并在根据能力信息确定第一物理网卡具备指定能力的情况下，确定将流表配置到第一物理网卡中；或者，在根据能力信息确定第一物理网卡不具备指定能力的情况下，确定在本地维护流表。

在本实施例中，借助于云原生基础组件，一方面可解耦上层应用对硬件资源的直接依赖，即上层应用不再直接与硬件资源进行交互，而是由云原生基础组件与硬件资源进行交互，这点与虚拟化技术会屏蔽上层应用对物理资源的依赖的特性相适配；另一方面，通过在数据面上旁路计算节点的内核协议栈，可减少因将数据报文送入内核协议栈产生的中断次数，减少数据报文从内核态向用户态拷贝的次数，从而为云网络系统中的上层应用提供数据面加速服务，解决云网络系统面临的数据面加速问题。另外，在计算节点中部署云原生基础组件，对上层应用的开发和部署几乎没影响，不再依赖上层应用的数据面开发，还可以降低用户对上层应用的开发和部署难度，而且可以做到任何计算节点无差异部署，具有较强的实施灵活性。

在本申请上述实施例中，并不对“上层应用”的实现进行限定，“上层应用”可以是任何具有数据传输需求的云原生应用，下面以上层应用是5G上云场景中基于云原生技术开发的5G应用和自动驾驶场景中负责大数据处理的自动驾驶应用为例进行说明。

在一可选实施例中，部署在计算节点上的上层应用可以是基于云原生技术开发的5G应用，5G应用是指基于第五代移动通信技术(5th Generation Mobile CommunicationTechnology，5G)的应用，例如可以是但不限于：5G远程手术、5G多媒体服务、5G超高清视频转播等等。在本申请实施例中，可以借助于云原生技术将这些应用开发为云原生应用，例如云原生的5G远程手术、5G多媒体服务、5G超高清视频转播的应用，并将这些应用部署在云网络系统中的计算节点上。这些5G应用在运行过程中需要进行数据传输。在本实施例中，计算节点上提供了为5G云原生应用提供数据面加速服务的云原生基础组件，该云原生基础组件面向5G云原生应用提供服务接口。

以5G远程手术应用为例，远端医疗现场具有机械臂和摄像头，摄像头采集现场医疗画面并上传至云端的5G远程手术应用，5G远程手术应用将该现场医疗画面传输给医生端，医生端根据云端传输过来的医疗现场画面生成对机械臂的操作信号，并上传至5G远程手术应用，由5G远程手术应用将操作信号传输给远端医疗现场的机械臂，进而控制机械臂执行手术操作。由于现场医疗画面需要保证高清晰度，故对5G远程手术应用的视频处理能力要求较高，而在本申请实施例中，由于5G远程手术应用被部署到了云网络系统中，可以充分发挥云网络的资源弹性和分布式优势，为5G远程手术应用分配足够的计算和网络资源，以便于保证5G远程手术应用能够提供高清晰度的医疗现场画面和具有较低传输时延，确保手术的实时性，保证生命体征平稳。另外，为了进一步保证手术的实时性，还可以借助于云原生基础组件的优势，在进行现场医疗画面和操作信号传输时，直接由用户空间对物理网卡进行收发控制，旁路OS中的内核协议栈，使得现场医疗画面可以直接从物理网卡被拷贝到用户空间，不再是先从物理网卡到内核空间再从内核空间到用户空间，减少内存拷贝次数，节约时间，提高传输效率；对操作信号类似，可以直接从用户空间到达物理网卡，不再是先从用户空间到内核空间再从内核空间到物理网卡，同样可以减少拷贝次数，节约时间，提高效率。另外，在从物理网卡到内核空间或从用户空间到内核空间时，需要产生中断，而本案还可以减少中断次数，可进一步提高数据处理效率。

以5G超高清视频转播应用为例，5G超高清视频转播应用接收来自卫星系统或其上游CDN节点发送来的原始高清视频，例如可以是各种比赛视频；然后，对接收到的原始高清视频进行解压缩、解码、转码、重新编码、压缩等处理后，重新形成适合播放终端的目标高清视频，并将该目标高清视频传输给播放终端进行解压缩、解码以及播放处理；其中，播放终端可以是适合播放高清视频的手机、电视、智能大屏或笔记本电脑等。由于高平视频转播需要保证画面具有高清晰度，故对5G超高清视频转播应用的视频处理能力要求较高，而在本申请实施例中，由于5G超高清视频转播应用被部署到了云网络系统中，可以充分发挥云网络的资源弹性和分布式优势，为5G超高清视频转播应用分配足够的计算资源和网络资源，以便于保证5G超高清视频转播应用能够提供超高清视频画面、较低传输时延和播放流畅度，保证观看转播视频的用户的体验度。另外，为了进一步转播视频的实时性，还可以借助于云原生基础组件的优势，在进行原始高清视频和目标高清视频传输时，直接由用户空间对物理网卡进行收发控制，旁路OS中的内核协议栈，使得原始高清视频可以直接从物理网卡被拷贝到用户空间，不再是先从物理网卡到内核空间再从内核空间到用户空间，减少内存拷贝次数，节约时间，提高传输效率；对目标高清视频类似，可以直接从用户空间到达物理网卡，不再是先从用户空间到内核空间再从内核空间到物理网卡，同样可以减少拷贝次数，节约时间，提高效率。另外，在从物理网卡到内核空间或从用户空间到内核空间时，需要产生中断，而本案还可以减少中断次数，可进一步提高数据处理效率。

在另一可选实施例中，部署在计算节点上的上层应用还可以是基于云原生技术开发的自动驾驶应用。具体地，车辆要实现在道路上完全的自动驾驶，除了要依靠车辆本身带有的摄像头、毫米波雷达、激光雷达等传感器进行实时路况数据的采集之外，还要对采集到的大量传感器数据进行处理并根据处理结果做出驾驶决策。在本实施例中，借助于云原生技术、云计算能力和云存储能力，将对大量传感器数据的存储、处理和决策等功能实现为云原生的自动驾驶应用，将该自动驾驶应用部署到云网络系统中的计算节点上，用以提供自动驾驶决策。另外，为了保证自动驾驶应用的数据传输效率，在本实施例的计算节点上部署有用于提供数据面加速服务的云原生基础组件，该云原生基础组件面向自动驾驶应用提供服务接口。基于此，车辆上各传感器采集到传感器数据之后可以上报给云端的自动驾驶应用，自动驾驶应用所在计算节点上的物理网卡接收到传感器数据，将传感器数据提供给云原生基础组件，云原生基础组件基于该服务接口将传感器数据上报给自动驾驶应用；自动驾驶应用对传感器数据进行清洗和联合分析等一些系列处理后，基于处理后的传感器数据生成驾驶决策，并通过服务接口将驾驶决策下发给云原生基础组件，由云原生基础组件通过与之适配的物理网卡发送出去，并在经过网络传输后到达车辆，车辆根据该驾驶决策进行自动驾驶，该驾驶决策中包括避让轨迹、是否变道、行驶速度等各种自动驾驶所需的参数。在本实施例中，基于云原生基础组件，无论是传感器数据还是驾驶决策可以不经过内核协议栈的处理，而是直接从物理网卡到达自动驾驶应用或者直接从自动驾驶应用到达物理网卡，自动驾驶应用属于用户空间，数据直接在物理网卡与用户空间之间进行传输，可减少中断次数和内存拷贝次数，有利于减少数据处理时延，可提高数据处理效率，可满足自动驾驶对驾驶决策实时性的要求。

在上述场景实施例中，现场医疗画面、操作信号、原始高清视频、目标高清视频、传感器数据和驾驶决策等都是上文中数据报文的示例；另外，在上述场景实施例中，均以数据报文需上传至相应云原生应用进行处理为例进行说明，但并不限于此。对于一些简单的数据报文处理逻辑，云原生应用可以通过服务接口下发流表到物理网卡或云原生基础组件，这样数据报文经物理网卡或云原生基础组件进行处理后即可直接转发出去，无需云原生应用的参与，可进一步提高数据处理效率。

另外，本申请实施例中的上层应用还可以是云上直播应用，为了提高直播数据传输效率，在本申请实施例中，提供一种直播数据传输方法，应用于部署有云上直播应用的计算节点，该计算节点上还部署有可为云上直播应用提供数据面加速服务的云原生基础组件，如图4b所示，该方法包括：

41、云原生基础组件响应响应来自直播端的直播传输请求，所述直播传输请求指向云上直播应用。

42、旁路云原生基础组件所在计算节点的内核协议栈，调用该计算节点的硬件资源为云上直播应用提供直播数据传输服务，所述硬件资源至少包括与云原生基础组件适配的第一物理网卡。

在本实施例中，云上直播应用可以部署在中心云系统或边缘云系统中的边缘云节点中，负责接收直播端提供的直播数据，例如可以是游戏直播数据、电商直播数据、新闻发布直播数据等；之后对这些直播数据进行视频处理，例如对这些直播数据进行编解码、打水印、质量审核、给一些直播数据打点、添加字幕、美颜或添加文字说明等；之后，云上直播应用可以将处理后的直播数据直接发送给观看端，或者发送至内容分发网络(CDN)中的CDN节点上，以供观看端就近从CDN节点上获取所需的直播数据。

在本实施例的计算节点上部署有用于提供数据面加速服务的云原生基础组件，该云原生基础组件包括第一组件和第二组件；第一组件用于提供访问上述硬件资源所需的库函数；第二组件用于面向上层应用提供服务接口和对库函数的调用。基于此，可以预先基于库函数配置第一物理网卡针对直播数据的收发逻辑，以使第一物理网卡将来自直播端的直播数据上报给第二组件。基于此，直播端生成直播数据之后可以上报给云上直播应用，云上直播应用所在计算节点上的第一物理网卡接收直播数据，并将直播数据提供给云原生基础组件中的第二组件，第二组件基于其提供的服务接口将直播数据上报给云上直播应用；云上直播应用对直播数据进行编解码、打水印、质量审核、打点、添加字幕、美颜或添加文字说明等一些系列处理后，通过服务接口将处理后的直播数据下发给第二组件，由第二组件通过第一物理网卡发送给观看端或CDN节点。其中，打点是指对直播数据中的关键帧数据进行描述，这样直播数据在播放时把鼠标放在播放进度条上会显示接下来的直播数据。

进一步，在直播数据被传输到CDN节点时，CDN节点上也可以部署用于提供数据面加速服务的云原生基础组件，具体地，CDN节点上的CDN应用可以预先将用于直播数据转发的流表下发给云原生基础组件中的第二组件，由第二组件在本地维护流表，或者在第一物理网卡为智能网卡的情况下，将流表配置到第一物理网卡中；这样，当第一物理网卡接收到直播数据时，或者上报第二组件，由第二组件根据流表进行转发处理后再转发出去，或者是直接根据流表对直播数据进行转发处理后再转发出去，具体可以转发给下一个CDN节点或者观看端。

在上述数据传输过程中，可借助于云原生基础组件的优势，在进行直播数据传输时，直接由用户空间对物理网卡进行收发控制，旁路OS中的内核协议栈，使得直播数据可以直接从物理网卡被拷贝到用户空间或者直接从用户空间被拷贝到物理网卡，不再是先从物理网卡到内核空间再从内核空间到用户空间，减少内存拷贝次数，节约时间，提高传输效率。另外，在从物理网卡到内核空间或从用户空间到内核空间时，需要产生中断，而本案还可以减少中断次数，可进一步提高数据处理效率。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤401至步骤402的执行主体可以为设备A；又比如，步骤401的执行主体可以为设备A，步骤402的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如401、402等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图5为本申请示例性实施例提供的一种云原生基础组件的结构示意图。本实施例提供的云原生基础组件可部署到云网络系统中的计算节点中，为计算节点上的上层应用提供数据面加速服务，具体可响应来自数据面的数据传输请求，旁路其所在计算节点的内核协议栈，调用计算节点的硬件资源为与数据传输请求对应的上层应用提供数据传输服务，硬件资源至少包括与云原生基础组件适配的第一物理网卡。如图5所示，该云原生基础组件50包括：第一组件51和第二组件52；第一组件51集成在计算节点的操作系统OS中，用于提供访问计算节点的硬件资源所需的库函数；第一组件52部署在计算节点上依赖OS的目标计算环境中，用于面向部署在虚拟化计算环境中的上层应用提供服务接口和对库函数的调用功能，以旁路内核协议栈为上层应用提供数据面加速服务。

在一可选实施例中，在虚拟化计算环境是采用容器技术实现的容器的情况下，目标计算环境可以是计算节点提供的容器；或者，在虚拟化计算环境是采用虚拟机技术实现的虚拟机的情况下，目标计算环境是计算节点提供的非虚拟化计算环境。在图5中，以计算节点采用容器技术为例，并且以上层应用部署在pod中，第二组件部署在pod中为例进行图示。

在一可选实施例中，第二组件52具体用于：在数据传输请求为数据转发请求的情况下，基于服务接口和库函数控制第一物理网卡为上层应用进行数据报文转发。

进一步，第二组件基于服务接口和库函数控制第一物理网卡为上层应用进行数据报文转发，具体包括：

预先在本地维护上层应用通过服务接口下发的用于数据转发的流表，并基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡将接收到的数据报文上报给第二组件；以及在接收到第一物理网卡上报的数据报文时，基于流表对数据报文进行处理并通过第一物理网卡将处理后的数据报文转发出去；

或者，

预先将上层应用通过服务接口下发的用于数据转发的流表配置到第一物理网卡中，并基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡根据流表对接收到的数据报文进行转发处理；

或者，

预先基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡将接收到的数据报文上报给第二组件；以及在接收到第一物理网卡上报的数据报文时，基于服务接口将数据报文上报给上层应用进行处理并接收上层应用处理后的数据报文，通过第一物理网卡将处理后的数据报文转发出去。

在一可选实施例中，第二组件还用于：获取第一物理网卡和云原生基础组件的能力信息，并上报给上层应用，以供上层应用确定流表的配置信息，配置信息包括流表的配置位置为第二组件或第一物理网卡；以及根据上层应用下发的配置信息中的配置位置，将流表配置在本地或第一物理网卡上；

或者，

获取第一物理网卡的能力信息，并在根据能力信息确定第一物理网卡具备指定能力的情况下，确定将流表配置到第一物理网卡中；或者，在根据能力信息确定第一物理网卡不具备指定能力的情况下，确定在本地维护流表。

在一可选实施例中，第二组件还用于：基于库函数配置第一物理网卡的协议报文转发逻辑，以使第一物理网卡将接收到的协议报文上报给第二组件；以及在接收到第一物理网卡上报的协议报文时，基于内核接口机制或虚拟网卡设备，将协议报文传输给计算节点的OS，以供该OS基于内核协议栈对协议报文进行协议栈处理后提供给上层应用。

在一可选实施例中，计算节点还包括：与OS适配的第二物理网卡，第二物理网卡用于负责与上层应用对应的协议报文的转发；OS还用于：在第二物理网卡接收到的协议报文的情况下，利用内核协议栈对协议报文进行协议栈处理后提供给上层应用。

图6为本申请示例性实施例提供的一种计算节点的结构示意图。如图6所示，该计算节点包括：存储器61和处理器62。

存储器61，用于存储计算机程序，并可被配置为存储其它各种数据以支持在计算节点上的操作。这些数据的示例包括用于在计算节点上操作的任何应用程序或方法的指令，消息，图片，视频等。存储器61可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

在本实施例中，存储器61中用于存储虚拟化程序；处理器62与所述存储器61耦合，用于执行所述虚拟化程序，以用于：采用虚拟化技术在所述计算节点上提供虚拟化计算环境，所述虚拟化计算环境用于承载上层应用。

进一步，存储器61中还用于存储为所述上层应用提供数据面加速服务的云原生基础组件，处理器62还用于执行所述云原生基础组件，以用于：响应来自数据面的数据传输请求，旁路其所在计算节点的内核协议栈，调用所述计算节点的硬件资源为与所述数据传输请求对应的上层应用提供数据传输服务，所述硬件资源至少包括与所述云原生基础组件适配的第一物理网卡63，如图6所示。

进一步，本实施例的云原生基础组件包括：第一组件和第二组件；第一组件集成在计算节点的OS中，用于提供访问计算节点的硬件资源所需的库函数；第一组件部署在计算节点上依赖OS的目标计算环境中，用于面向部署在虚拟化计算环境中的上层应用提供服务接口和对库函数的调用功能，以旁路内核协议栈为上层应用提供数据面加速服务。

基于上述，处理器62具体用于可运行第二组件，以用于：在数据传输请求为数据转发请求的情况下，基于服务接口和库函数控制第一物理网卡为上层应用进行数据报文转发。

进一步可选地，处理器62基于服务接口和库函数控制第一物理网卡为上层应用进行数据报文转发，具体用于：

预先在本地维护上层应用通过服务接口下发的用于数据转发的流表，并基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡将接收到的数据报文上报给第二组件；以及在接收到第一物理网卡上报的数据报文时，基于流表对数据报文进行处理并通过第一物理网卡将处理后的数据报文转发出去；

或者，

预先将上层应用通过服务接口下发的用于数据转发的流表配置到第一物理网卡中，并基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡根据流表对接收到的数据报文进行转发处理；

或者，

预先基于库函数配置第一物理网卡的数据报文收发逻辑，以使第一物理网卡将接收到的数据报文上报给第二组件；以及在接收到第一物理网卡上报的数据报文时，基于服务接口将数据报文上报给上层应用进行处理并接收上层应用处理后的数据报文，通过第一物理网卡将处理后的数据报文转发出去。

在一可选实施例中，处理器62还用于：获取第一物理网卡和云原生基础组件的能力信息，并上报给上层应用，以供上层应用确定流表的配置信息，配置信息包括流表的配置位置为第二组件或第一物理网卡；以及根据上层应用下发的配置信息中的配置位置，将流表配置在本地或第一物理网卡上；

或者，

获取第一物理网卡的能力信息，并在根据能力信息确定第一物理网卡具备指定能力的情况下，确定将流表配置到第一物理网卡中；或者，在根据能力信息确定第一物理网卡不具备指定能力的情况下，确定在本地维护流表。

在一可选实施例中，处理器62还用于：基于库函数配置第一物理网卡的协议报文转发逻辑，以使第一物理网卡将接收到的协议报文上报给第二组件；以及在接收到第一物理网卡上报的协议报文时，基于内核接口机制或虚拟网卡设备，将协议报文传输给计算节点的OS，以供该OS基于内核协议栈对协议报文进行协议栈处理后提供给上层应用。

在一可选实施例中，计算节点还包括：与OS适配的第二物理网卡64，第二物理网卡64用于负责与上层应用对应的协议报文的转发；处理器62还用于运行OS，以用于：在第二物理网卡接收到的协议报文的情况下，利用内核协议栈对协议报文进行协议栈处理后提供给上层应用。

进一步，如图6所示，该计算节点还包括：其它通信组件65、电源组件66等其它组件。图6中仅示意性给出部分组件，并不意味着计算节点只包括图6所示组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当计算机程序被处理器执行时，致使处理器能够实现图4a或图4b所示方法实施例中的各步骤。

相应地，本申请实施例还提供一种计算机程序产品，包括计算机程序/指令，当计算机程序/指令被处理器执行时，致使处理器能够实现图4a或图4b所示方法实施例中的各步骤。

上述图6中的其它通信组件被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G、3G、4G/LTE、5G等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。上述图6中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (14)

1.一种云网络系统，其特征在于，包括：多个计算节点，所述多个计算节点采用虚拟化技术提供虚拟化计算环境，所述虚拟化计算环境用于承载上层应用；所述多个计算节点上还部署有用于为所述上层应用提供数据面加速服务的云原生基础组件；

所述云原生基础组件，用于响应来自数据面的数据传输请求，旁路其所在计算节点的内核协议栈，调用所述计算节点的硬件资源为与所述数据传输请求对应的上层应用提供数据传输服务，所述硬件资源至少包括与所述云原生基础组件适配的第一物理网卡。

2.根据权利要求1所述的系统，其特征在于，所述云原生基础组件包括第一组件和第二组件；所述第一组件集成在所述计算节点的操作系统OS中，用于提供访问所述计算节点的硬件资源所需的库函数；所述第二组件部署在所述计算节点上依赖所述OS的目标计算环境中，用于面向部署在所述虚拟化计算环境中的上层应用提供服务接口和对所述库函数的调用功能，以旁路所述内核协议栈为所述上层应用提供数据面加速服务。

3.根据权利要求2所述的系统，其特征在于，在所述虚拟化计算环境是采用容器技术实现的容器的情况下，所述目标计算环境是所述计算节点提供的容器；或者，在所述虚拟化计算环境是采用虚拟机技术实现的虚拟机的情况下，所述目标计算环境是所述计算节点提供的非虚拟化计算环境。

4.根据权利要求2或3所述的系统，其特征在于，所述第二组件具体用于：在所述数据传输请求为数据转发请求的情况下，基于所述服务接口和所述库函数控制所述第一物理网卡为所述上层应用进行数据报文转发。

5.根据权利要求4所述的系统，其特征在于，所述第二组件基于所述服务接口和所述库函数控制所述第一物理网卡为所述上层应用进行数据报文转发，具体包括：

预先在本地维护所述上层应用通过所述服务接口下发的用于数据转发的流表，并基于所述库函数配置所述第一物理网卡的数据报文收发逻辑，以使所述第一物理网卡将接收到的数据报文上报给所述第二组件；以及在接收到所述第一物理网卡上报的数据报文时，基于所述流表对所述数据报文进行处理并通过所述第一物理网卡将处理后的数据报文转发出去；

或者

预先将所述上层应用通过所述服务接口下发的用于数据转发的流表配置到所述第一物理网卡中，并基于所述库函数配置所述第一物理网卡的数据报文收发逻辑，以使所述第一物理网卡根据所述流表对接收到的数据报文进行转发处理；

或者

预先基于所述库函数配置所述第一物理网卡的数据报文收发逻辑，以使所述第一物理网卡将接收到的数据报文上报给所述第二组件；以及在接收到所述第一物理网卡上报的数据报文时，基于所述服务接口将所述数据报文上报给所述上层应用进行处理并接收所述上层应用处理后的数据报文，通过所述第一物理网卡将所述处理后的数据报文转发出去。

6.根据权利要求5所述的系统，其特征在于，所述第二组件还用于：获取所述第一物理网卡和所述云原生基础组件的能力信息，并上报给所述上层应用，以供所述上层应用确定所述流表的配置信息，所述配置信息包括所述流表的配置位置为所述第二组件或所述第一物理网卡；以及根据所述上层应用下发的所述配置信息中的配置位置，将所述流表配置在本地或所述第一物理网卡上；

或者，

获取所述第一物理网卡的能力信息，并在根据所述能力信息确定所述第一物理网卡具备指定能力的情况下，确定将所述流表配置到所述第一物理网卡中；或者，在根据所述能力信息确定所述第一物理网卡不具备指定能力的情况下，确定在本地维护所述流表。

7.根据权利要求2或3所述的系统，其特征在于，所述第二组件还用于：基于所述库函数配置所述第一物理网卡的协议报文转发逻辑，以使所述第一物理网卡将接收到的协议报文上报给所述第二组件；以及在接收到所述第一物理网卡上报的协议报文时，基于内核接口机制或虚拟网卡设备，将所述协议报文传输给所述OS，以供所述OS基于所述内核协议栈对所述协议报文进行协议栈处理后提供给所述上层应用。

8.根据权利要求1-3任一项所述的系统，其特征在于，所述云原生基础组件所在的计算节点还包括：与所述OS适配的第二物理网卡，所述第二物理网卡用于负责与所述上层应用对应的协议报文的转发；所述OS还用于：在所述第二物理网卡接收到的协议报文的情况下，利用所述内核协议栈对所述协议报文进行协议栈处理后提供给所述上层应用。

9.一种数据传输方法，其特征在于，应用于云网络系统中的计算节点，所述计算节点上部署有用于为上层应用提供数据面加速服务的云原生基础组件，所述方法包括：

所述云原生基础组件响应来自数据面的数据传输请求，旁路所述计算节点的内核协议栈，调用所述计算节点的硬件资源为与所述数据传输请求对应的上层应用提供数据传输服务，所述硬件资源至少包括与所述云原生基础组件适配的第一物理网卡。

10.根据权利要求9所述的方法，其特征在于，所述云原生基础组件包括第一组件和第二组件；所述第一组件用于提供访问所述硬件资源所需的库函数；所述第二组件用于面向上层应用提供服务接口和对所述库函数的调用功能；

则，在所述数据传输请求为数据转发请求的情况下，调用所述计算节点的硬件资源为与所述数据传输请求对应的上层应用提供数据传输服务，包括：基于所述服务接口和所述库函数控制所述第一物理网卡为所述上层应用进行数据报文转发。

11.一种直播数据传输方法，其特征在于，应用于云网络系统中的计算节点，所述计算节点上部署有用于为云上直播应用提供数据面加速服务的云原生基础组件，所述方法包括：

所述云原生基础组件响应来自直播端的直播传输请求，所述直播传输请求指向所述云上直播应用；

旁路所述计算节点的内核协议栈，调用所述计算节点的硬件资源为所述云上直播应用提供直播数据传输服务，所述硬件资源至少包括与所述云原生基础组件适配的第一物理网卡。

12.根据权利要求11所述的方法，其特征在于，所述云原生基础组件包括第一组件和第二组件；所述第一组件用于提供访问所述硬件资源所需的库函数；所述第二组件用于面向上层应用提供服务接口和对所述库函数的调用功能；

则，调用所述计算节点的硬件资源为所述云上直播应用提供直播数据传输服务，包括：基于所述库函数配置所述第一物理网卡针对直播数据的收发逻辑，以使所述第一物理网卡将来自直播端的直播数据上报给所述第二组件；

所述第二组件在接收到所述第一物理网卡上报的直播数据时，基于所述服务接口将所述直播数据上报给所述云上直播应用进行处理并接收所述云上直播应用处理后的直播数据，通过所述第一物理网卡将所述处理后的直播数据发送给观看端或内容分发网络CDN节点。

13.一种计算节点，应用于云网络系统中，其特征在于，所述计算节点包括：存储器和处理器；所述存储器中用于存储虚拟化程序；所述处理器与所述存储器耦合，用于执行所述虚拟化程序，以用于：采用虚拟化技术在所述计算节点上提供虚拟化计算环境，所述虚拟化计算环境用于承载上层应用；

所述存储器中还用于存储为所述上层应用提供数据面加速服务的云原生基础组件，所述处理器还用于执行所述云原生基础组件，以用于执行权利要求9-12任一项所述方法中的步骤。

14.一种存储有计算机程序的计算机可读存储介质，其特征在于，当所述计算机程序被处理器执行时，致使所述处理器实现权利要求9-12任一项所述方法中的步骤。

Images