CN113703784A - 基于容器编排的数据处理方法及装置 - Google Patents

Abstract

本申请提供基于容器编排的数据处理方法及装置，其中所述基于容器编排的数据处理方法包括：确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息；确定每个目标业务服务对应的目标服务容器，并根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路；接收所述待处理直播流；基于所述服务容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。通过本方法，可以将待处理直播流所需服务容器化，并实现自动化部署，只需要根据参数处理直播流即可，容器可以多次复用，方便快捷。

Description

基于容器编排的数据处理方法及装置

技术领域

本申请涉及互联网技术领域，特别涉及一种基于容器编排的数据处理方法。本申请同时涉及一种基于容器编排的数据处理装置，一种计算设备，以及一种计算机可读存储介质。

背景技术

随着互联网技术的发展，直播也得到了快速发展，在现有的直播体系中，直播平台会承办各种大型赛事的直播，对于大型赛事而言，源流和转码的稳定性将是非常关键的，如果由于直播流本身的不稳定或者卡顿或者断流，会导致观看直播的用户受到影响，同时为某个直播部署的服务在其他直播场次时无法再次使用，复用性较差。

发明内容

有鉴于此，本申请实施例提供了一种基于容器编排的数据处理方法。本申请同时涉及一种基于容器编排的数据处理装置，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的直播流因网络传输导致的高延迟，进而导致直播流卡顿或者断流现象，同时为直播部署的服务复用性较差的问题。

根据本申请实施例的第一方面，提供了一种基于容器编排的数据处理方法，包括：

确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息；

确定每个目标业务服务对应的目标服务容器，并根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路；

接收所述待处理直播流；

基于所述服务容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。

根据本申请实施例的第二方面，提供了一种基于容器编排的数据处理装置，包括：

确定模块，被配置为确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息；

编排模块，被配置为确定每个目标业务服务对应的目标服务容器，并根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路；

接收模块，被配置为接收所述待处理直播流；

处理模块，被配置为基于所述服务容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。

根据本申请实施例的第三方面，提供了一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，所述处理器执行所述计算机指令时实现所述基于容器编排的数据处理方法的步骤。

根据本申请实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现所述基于容器编排的数据处理方法的步骤。

本申请提供的基于容器编排的数据处理方法，确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息；确定每个目标业务服务对应的目标服务容器，并根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路；接收所述待处理直播流；基于所述服务容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。

本申请一实施例实现了将在直播过程中需要用到的服务进行容器化部署，确定每个服务所依赖的参数，在需要直播时，可以任意选择直播所需要的服务，并编排服务对应容器的启动顺序、传入参数等信息，最后调用直播流对应的容器调用链路，启动所有服务，实现自动化部署，服务对应的容器也与待处理直播流无关，只需要根据参数处理直播流即可，容器可以多次复用，方便快捷。

附图说明

图1是本申请一实施例提供的一种基于容器编排的数据处理方法的流程图；

图2是本申请一实施例提供的服务配置页面的示意图；

图3是本申请一实施例提供的容器编排界面的示意图；

图4是本申请一实施例提供的容器集群中赛事编排的结构示意图；

图5是本申请一实施例提供的一种应用于电子竞技赛事直播的基于容器编排的数据处理方法的处理流程图；

图6是本申请一实施例提供的一种基于容器编排的数据处理装置的结构示意图；

图7是本申请一实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本申请。但是本申请能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本申请内涵的情况下做类似推广，因此本申请不受下面公开的具体实施的限制。

在本申请一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本申请一个或多个实施例。在本申请一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本申请一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本申请一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本申请一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先，对本申请一个或多个实施例涉及的名词术语进行解释。

直播流：直播音视频数据的传输，它能被作为一个稳定的和连续的流通过网络传输给用户观看。

直播拉流：拉流是指直播云平台到用户指定的源站拉取直播流的过程。

DNS：域名解析服务，即将域名转换为IP的服务，例如，访问****.com，通过DNS查询该网站实际的访问服务器IP为*.*.*.*，然后访问该IP地址，域名和IP地址的映射关系是1对N的，即一个域名可以有多个服务器IP地址对应。

CDN：内容分发网络。

CDN服务商：提供内容分发网络的服务商。

容器：有效的将单个操作系统的资源划分到孤立的组中，以便更好的在孤立的组之间平衡有冲突的资源使用需求，这种技术就是容器技术。

容器集群：管理多个容器组的集群，可以全方位为应用集群实现自动化。

在现有的直播体系中，一般直播平台承办各种大型赛事，对于大型赛事而言，直播流和转码的稳定性将是非常关键的，如果由于直播流本身的不稳定或者卡顿或者断流，就会导致大量的观看用户收到影响，同时，大型赛事一般所依赖的服务的功能也很繁多。

为了保证赛事的正常直播，通常有两种方案，第一种是走一般直播流的推流逻辑，第二种是将服务都部署到一个集群中。第一种方案具体为所有直播流依赖的服务都在推流的边缘计算节点，转码等服务在中心服务节点，由于推流和转码等服务不在同一个节点，会因为网络传输等问题导致延迟较大，直播流容易受到网络传输的影响，导致直播流卡顿或者断流的现象频繁发生。第二种方案将所有的服务都部署在同一个集群，需要申请专门的云服务器，而且要依次部署直播所需要的服务，由于服务间的相互依赖关系，在部署服务时，还需要确定先后顺序，某一个服务的发版，会导致依赖的服务都需要人工发版，造成大量的人工浪费，而且每个服务在部署的时候，服务所配置的参数都与对应的赛事相关，即只可给单个赛事使用，整体服务在后期复用的可能性为0，某些赛事的比赛间隔会很长，也会浪费申请的云服务器的资源，因此该方案会导致针对特定赛事特定部署服务，浪费大量的人工。

基于此，在本申请中，提供了一种基于容器编排的数据处理方法，本申请同时涉及一种基于容器编排的数据处理装置，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本申请一实施例提供的一种基于容器编排的数据处理方法的流程图，具体包括以下步骤：

步骤102：确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息。

待处理直播流即赛事直播的直播流，赛事直播可以为电子竞技赛事直播、体育竞技赛事直播等等，赛事直播在正式比赛之前会有详细的比赛计划，可以获知该赛事的直播流所需要哪些服务，为了保证赛事直播的正常运行，需要先为赛事直播预先配置好相应的服务。

目标业务服务具体是指待处理直播流所需要用到的服务，例如，转码服务、推流服务、拉流服务等等，业务服务调用信息具体是在直播过程中，待处理直播流应用服务的先后顺序，即服务间的依赖关系，例如，对于待处理直播流，需要先进行拉流服务，再进行转码服务，再进行存储服务，最后再进行推流服务等等。

在赛事之前，可以确定赛事对应的直播流都需要应用到哪些服务，同时还可以确定服务间的依赖顺序，即业务服务调用信息。

在本申请提供的一具体实施方式中，以某电子竞技游戏的直播赛事L为例，对赛事L进行直播生成的直播流即为待处理直播流，对赛事L进行直播时，所需要使用到的服务即为目标业务服务，目标业务服务之间的先后执行顺序和服务间的依赖关系即为业务服务调用信息。

在本申请提供的基于容器编排的数据处理方法中，是基于容器编排的，因此，需要事先为每个业务服务配置各自对应的服务容器，即在确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息之前，所述方法还包括：

确定待处理业务服务；

将所述待处理业务服务做容器化处理，生成所述待处理业务服务对应的服务容器。

待处理业务服务即在视频流处理过程中涉及到的业务服务，具体的，所述待处理业务服务包括视频流处理服务，例如，导播台服务、Flv转码服务、Hls转码服务、边缘计算上行服务，转推服务、4K超分服务等等。

导播台服务，主要负责对赛事的源流进行初始化处理，例如有2个输入源，一主一备，在输出的时候，由导播台进行健康判断，并输入健康的直播流，或对流进行码率的压缩，增加流水印等等。

Flv转码服务，是现在大多数直播平台都具备的转码方式，是指将直播流转码为不同分辨率和不同码率的转码流，Flv是一种输出封装格式。

Hls转码服务，也是一种将直播流转码为不同分辨率和不同码率的转码流的服务，Hls是一种输出封装格式，用于播放器播放。

边缘计算上行服务，是对直播流进行存储的服务。

转推服务，是将直播流转推到各家CDN的服务，如果一个直播流需要转推给各家CDN，则需要配置相应的转推服务，转推服务根据直播流的配置信息，可以精准的将直播流转推到各家CDN。

4K超分服务，是指利用AI超分辨率处理能力和视频编码优化，将1080P分辨率提升至4K分辨率，最后输出一个4K分辨率的直播流，提升用户观看体验。

在确定好与直播流相对应的待处理业务服务之后，即需要将每个待处理业务服务转化为对应的服务容器，将服务容器化，便于后续可以便捷的调用容器，提高容器的复用率。将所述待处理业务服务做容器化处理，生成所述待处理业务服务对应的服务容器，包括：

将所述待处理业务服务转化为对应的二进制文件；

将所述二进制文件上传至镜像托管平台，并在所述镜像托管平台中配置所述待处理业务服务对应的环境变量信息和/或配置信息，生成所述待处理业务服务对应的业务服务镜像文件；

根据所述业务服务镜像文件在容器集群中生成对应的服务容器。

具体的，先确定一个需要进行容器化的待处理业务服务，将该待处理业务服务打包生成二进制文件，用于后续创建服务容器使用。

镜像托管平台用于管理容器的镜像文件，当待处理业务服务的二进制文件被上传至镜像托管平台之后，在镜像托管平台中可以通过dockerfile文件对待处理业务服务所需要的环境变量和/或配置信息等进行配置，将待处理业务服务所依赖的各种环境变量打包在生成的业务服务镜像文件中，生成待处理业务服务对应的镜像文件，便于后续在对待处理业务服务进行更新时，可以对镜像文件进行更新，方便快捷。

在获得业务服务镜像文件后，就只需要部署该业务服务镜像文件即可，也就是根据该业务服务镜像文件在容器集群中生成对应的服务容器，做到打包一次镜像文件，后续可以重复复用的效果，提高服务的复用率。容器集群即为容器的编排管理系统，容器集群的基础系统是Kubernetes，简称k8s，Kubernetes用于自动部署，扩展和管理容器化应用程序的开源系统，它将组成应用程序的容器组合成逻辑单元，以便于管理和服务发现，通常情况下，容器集群被部署于云服务集群。在云服务集群上部署Kubernetes，并通过控制Kubernetes原生接口，实现启动容器和停止容器，以及容器间参数传递和容器编排。

步骤104：确定每个目标业务服务对应的目标服务容器，并根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路。

每个目标业务服务均对应一个目标服务容器，在确定目标业务服务之后，即可确定各自对应的目标服务容器，再根据业务服务调用信息对每个目标服务容器进行编排，确定每个目标服务容器的先后顺序，从而获得服务容器调用链路。

具体的，确定每个目标业务服务对应的目标服务容器，包括：

接收针对目标业务服务的容器启动指令，其中，所述容器启动指令中携带有目标业务服务标识和目标服务容器的配置启动参数；

根据所述目标业务服务标识确定容器集群中对应的目标服务容器，所述配置启动参数启动所述目标服务容器。

根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路，包括：

根据所述业务服务调用信息确定每个目标服务容器的容器顺序；

接收容器编排指令；

响应于所述容器编排指令确定每个目标服务容器中用于传递给下一个目标服务容器的传递参数；

根据所述容器顺序和每个目标服务容器的传递参数编排每个目标服务容器，生成服务容器调用链路。

在实际应用中，通常会在可视化界面中展示服务配置页面，在配置页面中接收针对目标业务服务的容器启动指令，同时选择要启动的服务和相关的环境配置参数。参见图2，图2示出了本申请一实施例提供的服务配置页面的示意图，在图2所示的“服务名字”即赛事名称，在服务名字处选择要直播的赛事或直播流的名称，例如“**活动”。然后选择部署平台，并选择需要部署的目标业务服务，在实际应用中，还会有应用组和集群供用户选择，用户可以选择一个用于部署的集群。

如图2所示，在配置页面中还会有与待处理直播流对应的环境参数，用户可以根据不同的赛事情况选择适合的配置，如CPU配置、内存配置以及相关的环境变量。

在对赛事属性信息、属性信息进行设置完成之后，即可在根据业务服务调用信息在容器配置页面对目标服务容器进行顺序的编排。参见图3，图3示出了本申请一实施例提供的容器编排界面的示意图，如图3所示，根据业务服务调用信息，先将服务划分不不同的步骤，如step1、step2、step3等等，在每个步骤中，选择相应的服务容器，并确定该服务容器的下一个服务容器是哪个，即依赖服务，确定参数的传递顺序，再确定传递给下一个服务容器的具体参数，在容器编排界面完成每个服务容器的参数配置，以及依赖关系的顺序。

在完成上述配置之后，即生成了该待处理直播流的服务容器调用链路，完成了后续处理待处理直播流的准备工作。

步骤106：接收所述待处理直播流。

在直播赛事开始之时，直播平台即开始接收待处理直播流，同一个赛事中可能会有不同的拍摄机位，也会有多个待处理直播流，在实际应用中，对待处理直播流的数量不做限定，只需要保证待处理直播流是与直播赛事相关即可，待处理直播流的数量可以为一个、两个或多个。

步骤108：基于所述服务容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。

在获取待处理直播流之后，即可根据预先配置好的服务容器调用链路处理该待处理直播流，进而生成待处理直播流对应的目标直播流，并转发给用户。

参见图4，图4示出了本申请一实施例提供的容器集群中赛事编排的结构示意图，如图4所示，在容器集群中部署了2个赛事编排流程，在赛事编排1中，有两个拉流地址，即有两个待处理直播流，首先由导播台容器对待处理直播流进行初始化处理。再将待处理直播流经边缘计算上行容器进行存储，在赛事编排1中，需要对待处理直播流分别进行flv转码、hls转码和4K超分转码等处理，获得各自码率对应的目标直播流，再通过转推服务将目标直播流转推至多家CDN服务商，便于用户根据终端的实际情况来选择合适的目标直播流观看直播赛事。

在图4的赛事编排2中，只有一个拉流地址，即可以理解为只有一个待处理直播流，将该待处理直播流经由边缘计算上行容器处理后进行保存，并经由flv转码容器进行flv转码，获得目标直播流，最后经由转推服务容器转推至CDN服务商，便于用户观看直播赛事。

如图4所示，在容器集群中预先部署服务容器调用链路，在处理待处理直播流时，可以在容器集群中完成拉流、初始化、转码、转推等操作，由于在同一个容器集群中，内网传输，延迟较小，无网络抖动的风险，并且服务容器调用链路较短，使得待处理视频流的在处理过程中是稳定可靠的。

本申请提供的基于容器编排的数据处理方法，确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息；确定每个目标业务服务对应的目标服务容器，并根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路；接收所述待处理直播流；基于所述服务容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。通过本申请提供的方法，实现了将在直播过程中需要用到的服务进行容器化部署，确定每个服务所依赖的参数，在需要直播时，可以任意选择直播所需要的服务，并编排服务对应容器的启动顺序、传入参数等信息，最后调用直播流对应的容器调用链路，启动所有服务，实现自动化部署，服务对应的容器也与待处理直播流无关，只需要根据参数处理直播流即可，容器可以多次复用，方便快捷。

下述结合附图5，以本申请提供的基于容器编排的数据处理方法在电子竞技赛事直播的应用为例，对所述基于容器编排的数据处理方法进行进一步说明。其中，图5示出了本申请一实施例提供的一种应用于电子竞技赛事直播的基于容器编排的数据处理方法的处理流程图，具体包括以下步骤：

步骤502：确定用于视频直播的视频流处理服务。

在本申请提供的一具体实施例中，以电子竞技赛事L的直播处理为例进行解释说明。首先要先确定视频流处理的整体流程中会用到的视频流处理服务，例如拉流服务、初始化服务、转码服务、转推服务等等。

步骤504：将该视频流处理服务做容器化处理，生成该视频流处理服务对应的服务容器。

在本申请提供的一具体实施例中，沿用上例，将每个视频流处理服务分别进行容器化处理，在容器集群中部署每个视频流处理服务对应的服务容器。

步骤506：确定电子竞技赛事L直播的待处理直播流对应的4个直播流处理服务和直播流处理服务调用信息。

在本申请提供的一具体实施例中，沿用上例，在确定对电子竞技赛事L进行直播时，确定电子竞技赛事L的直播策略，即确定电子竞技赛事L的待处理直播流在处理过程中要经过拉流服务、边缘计算节点存储服务、转码服务和转推服务，同时确定直播流处理服务调用信息为“拉流服务-边缘计算节点存储服务-转码服务-转推服务”。

步骤508：确定每个直播流处理服务对应的直播流处理容器。

在本申请提供的一具体实施例中，沿用上例，确定拉流服务对应的容器为拉流容器，边缘计算节点存储服务对应的容器为边缘计算上行容器，转码服务对应的容器为flv转码容器，转推服务对应的容器为转推容器。

步骤510：根据直播流处理服务调用信息确定每个直播流处理容器的容器顺序。

在本申请提供的一具体实施例中，沿用上例，根据直播流处理服务调用信息确定容器顺序为“拉流容器-边缘计算上行容器-flv转码容器-转推容器”。

步骤512：接收容器编排指令，响应于所述容器编排指令确定每个直播流处理容器中用于传递给下一个直播流处理容器的传递参数。

在本申请提供的一具体实施例中，沿用上例，在容器编排界面接收容器编排指令，确定每个容器中的参数信息，并确定用于传递给下一个容器的传递参数。

步骤514：根据所述容器顺序和每个直播流处理容器的传递参数编排每个直播流处理容器，生成直播流容器调用链路。

在本申请提供的一具体实施例中，沿用上例，根据所述容器顺序和每个容器的传递参数编排拉流容器、边缘计算上行容器、flv转码容器、转推容器，生成“拉流容器-边缘计算节点上行容器-flv转码容器-转推容器”的直播流容器调用链路。

步骤516：接收电子竞技赛事L的待处理直播流。

在本申请提供的一具体实施例中，沿用上例，开始对电子竞技赛事L进行直播，获取电子竞技赛事L的待处理直播流。

步骤518：基于直播流容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。

在本申请提供的一具体实施例中，沿用上例，根据“拉流容器-边缘计算节点上行容器-flv转码容器-转推容器”的直播流容器调用链路处理待处理直播流，获得目标视频流，并将目标视频流转发至相应的CDN节点，以供用户观看电子竞技赛事L的直播。

本申请提供的基于容器编排的数据处理方法，确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息；确定每个目标业务服务对应的目标服务容器，并根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路；接收所述待处理直播流；基于所述服务容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。通过本申请提供的方法，实现了将在直播过程中需要用到的服务进行容器化部署，确定每个服务所依赖的参数，在需要直播时，可以任意选择直播所需要的服务，并编排服务对应容器的启动顺序、传入参数等信息，最后调用直播流对应的容器调用链路，启动所有服务，实现自动化部署，服务对应的容器也与待处理直播流无关，只需要根据参数处理直播流即可，容器可以多次复用，方便快捷。

与上述基于容器编排的数据处理方法实施例相对应，本申请还提供了基于容器编排的数据处理装置实施例，图6示出了本申请一实施例提供的一种基于容器编排的数据处理装置的结构示意图。如图6所示，该装置包括：

确定模块602，被配置为确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息；

编排模块604，被配置为确定每个目标业务服务对应的目标服务容器，并根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路；

接收模块606，被配置为接收所述待处理直播流；

处理模块608，被配置为基于所述服务容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。

可选的，所述装置还包括：

服务确定模块，被配置为确定待处理业务服务；

容器化模块，被配置为将所述待处理业务服务做容器化处理，生成所述待处理业务服务对应的服务容器。

可选的，所述容器化模块，进一步被配置为：

将所述待处理业务服务转化为对应的二进制文件；

将所述二进制文件上传至镜像托管平台，并在所述镜像托管平台中配置所述待处理业务服务对应的环境变量信息和/或配置信息，生成所述待处理业务服务对应的业务服务镜像文件；

根据所述业务服务镜像文件在容器集群中生成对应的服务容器。

可选的，所述编排模块604，进一步被配置为：

接收针对目标业务服务的容器启动指令，其中，所述容器启动指令中携带有目标业务服务标识和目标服务容器的配置启动参数；

根据所述目标业务服务标识确定容器集群中对应的目标服务容器，所述配置启动参数启动所述目标服务容器。

可选的，所述编排模块604，进一步被配置为：

根据所述业务服务调用信息确定每个目标服务容器的容器顺序；

接收容器编排指令；

响应于所述容器编排指令确定每个目标服务容器中用于传递给下一个目标服务容器的传递参数；

根据所述容器顺序和每个目标服务容器的传递参数编排每个目标服务容器，生成服务容器调用链路。

可选的，所述容器集群被部署于云服务集群。

可选的，所述待处理业务服务包括视频流处理服务。

本申请提供的基于容器编排的数据处理装置，确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息；确定每个目标业务服务对应的目标服务容器，并根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路；接收所述待处理直播流；基于所述服务容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。通过本申请提供的装置，实现了将在直播过程中需要用到的服务进行容器化部署，确定每个服务所依赖的参数，在需要直播时，可以任意选择直播所需要的服务，并编排服务对应容器的启动顺序、传入参数等信息，最后调用直播流对应的容器调用链路，启动所有服务，实现自动化部署，服务对应的容器也与待处理直播流无关，只需要根据参数处理直播流即可，容器可以多次复用，方便快捷。

上述为本实施例的一种基于容器编排的数据处理装置的示意性方案。需要说明的是，该基于容器编排的数据处理装置的技术方案与上述的基于容器编排的数据处理方法的技术方案属于同一构思，基于容器编排的数据处理装置的技术方案未详细描述的细节内容，均可以参见上述基于容器编排的数据处理方法的技术方案的描述。

图7示出了根据本申请一实施例提供的一种计算设备700的结构框图。该计算设备700的部件包括但不限于存储器710和处理器720。处理器720与存储器710通过总线730相连接，数据库750用于保存数据。

计算设备700还包括接入设备740，接入设备740使得计算设备700能够经由一个或多个网络760通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备740可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本申请的一个实施例中，计算设备700的上述部件以及图7中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图7所示的计算设备结构框图仅仅是出于示例的目的，而不是对本申请范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备700可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备700还可以是移动式或静止式的服务器。

其中，处理器720执行所述计算机指令时实现所述的基于容器编排的数据处理方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的基于容器编排的数据处理方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述基于容器编排的数据处理方法的技术方案的描述。

本申请一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该计算机指令被处理器执行时实现如前所述基于容器编排的数据处理方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的基于容器编排的数据处理方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述基于容器编排的数据处理方法的技术方案的描述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本申请所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本申请优选实施例只是用于帮助阐述本申请。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本申请的内容，可作很多的修改和变化。本申请选取并具体描述这些实施例，是为了更好地解释本申请的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本申请。本申请仅受权利要求书及其全部范围和等效物的限制。

Claims (10)

1.一种基于容器编排的数据处理方法，其特征在于，包括：

确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息；

确定每个目标业务服务对应的目标服务容器，并根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路；

接收所述待处理直播流；

基于所述服务容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。

2.如权利要求1所述的基于容器编排的数据处理方法，其特征在于，在确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息之前，所述方法还包括：

确定待处理业务服务；

将所述待处理业务服务做容器化处理，生成所述待处理业务服务对应的服务容器。

3.如权利要求2所述的基于容器编排的数据处理方法，其特征在于，将所述待处理业务服务做容器化处理，生成所述待处理业务服务对应的服务容器，包括：

将所述待处理业务服务转化为对应的二进制文件；

将所述二进制文件上传至镜像托管平台，并在所述镜像托管平台中配置所述待处理业务服务对应的环境变量信息和/或配置信息，生成所述待处理业务服务对应的业务服务镜像文件；

根据所述业务服务镜像文件在容器集群中生成对应的服务容器。

4.如权利要求1-3任意一项所述的基于容器编排的数据处理方法，其特征在于，确定每个目标业务服务对应的目标服务容器，包括：

接收针对目标业务服务的容器启动指令，其中，所述容器启动指令中携带有目标业务服务标识和目标服务容器的配置启动参数；

根据所述目标业务服务标识确定容器集群中对应的目标服务容器，所述配置启动参数启动所述目标服务容器。

5.如权利要求1-3任意一项所述的基于容器编排的数据处理方法，其特征在于，根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路，包括：

根据所述业务服务调用信息确定每个目标服务容器的容器顺序；

接收容器编排指令；

响应于所述容器编排指令确定每个目标服务容器中用于传递给下一个目标服务容器的传递参数；

根据所述容器顺序和每个目标服务容器的传递参数编排每个目标服务容器，生成服务容器调用链路。

6.如权利要求3所述的基于容器编排的数据处理方法，其特征在于，所述方法还包括：

所述容器集群被部署于云服务集群。

7.如权利要求2所述的基于容器编排的数据处理方法，其特征在于，所述方法还包括：

所述待处理业务服务包括视频流处理服务。

8.一种基于容器编排的数据处理装置，其特征在于，包括：

确定模块，被配置为确定待处理直播流对应的至少一个目标业务服务和业务服务调用信息；

编排模块，被配置为确定每个目标业务服务对应的目标服务容器，并根据所述业务服务调用信息编排每个目标服务容器，获得服务容器调用链路；

接收模块，被配置为接收所述待处理直播流；

处理模块，被配置为基于所述服务容器调用链路处理所述待处理直播流，生成所述待处理直播流对应的目标视频流。

9.一种计算设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机指令，其特征在于，所述处理器执行所述计算机指令时实现权利要求1-7任意一项所述方法的步骤。

10.一种计算机可读存储介质，其存储有计算机指令，其特征在于，该计算机指令被处理器执行时实现权利要求1-7任意一项所述方法的步骤。

Images