Docker容器技术在电影公益放映系统中的部署实践

丁 鑫

中央宣传部电影数字节目管理中心，北京 100866

1 引言

随着公共文化的不断发展，电影公益放映的场景模式在不断增加。为了满足多场景的放映需求，通过将电影公益放映系统中的影片订购、制作、授权等相关应用服务模块高效拆分和组合，来达到快速响应并适配新业务场景十分必要。在探索电影公益放映服务模式的过程中，通过Docker 容器技术在电影公益放映的系统建设部署实践，实现对不同功能模块的快速拆分、耦合，不但可以快速适配电影放映的不同场景，也是节省成本且灵活高效的解决方案。本文对Docker 容器部署电影发行版制版、场次回传以及播放器设备注册等服务部署实践过程进行了总结。

2 电影公益放映系统的背景

2002 年，文化部、国家发展和改革委员会及国家广播电影电视总局启动了农村电影放映“2131 工程”（即在21 世纪初实现“一村一月放映一场电影”），旨在丰富西部地区和老少边贫地区农民群众的精神文化生活，解决农民群众看电影难的问题。电影数字节目管理中心（以下简称“中心”）正是为了承担该计划的职责和使命而成立的机构。中心于2006 年开发并上线了第一版集订购、制作、注册、授权、回传等功能于一体的电影公益放映信息化平台。

随着时间的推移，电影公益放映系统不断完善和发展，在农村地区、城市社区、学校、医院等公共场所得到了广泛的应用。目前，电影公益放映系统已经成为中国电影文化推广的重要渠道之一，为广大群众提供了丰富多彩的电影文化体验。但是，随着时代与科技的进步，十多年前设计开发的平台已经凸显了一些问题，主要有以下几点：

（1）经过多次的功能再升级，平台功能模块众多，数据间交互错综复杂；

（2）系统设计初期只是为了服务于农村公益电影放映这一单一场景，在当下要求放映场景多样化的情况下，无法快速拆分耦合适应新的放映场景；

（3）使用的技术栈落后，旧代码经过十多年的更新迭代效率已经十分低下；

（4）平台底层架构一直为传统信息化系统架构，后续的横向纵向扩展都比较困难，无法满足大数据量和计算量的需求。

针对这些亟待解决的问题，结合电影公益放映平台的特点，我们认为通过重构平台底层架构、引入容器和K8S 等技术栈的手段，升级改造出一个可以适应多放映场景的、模块可以快速拆分耦合的、页面设计现代化的、使用逻辑简单方便且运行稳定高效流畅的新电影公益放映信息化平台十分必要。

本文基于以上目标，实践了公益电影信息化平台的制版、授权、回传、注册等模块的容器化改造，并对改造后的几个重要指标进行了对比，为后续全方面的容器化改造提供了参考依据。

3 Docker 容器技术

Docker 是一个开源的容器化平台，其发展历程可以追溯到2008 年[1]，Docker 的创始人Solomon Hykes 曾在法国创立了一家PaaS 公司dotCloud，专注于开发和部署Web 应用程序。该平台采用了一种名为LXC（Linux Containers）的技术，可在单个Linux 操作系统实例中隔离应用程序。后来，该公司还使用了cgroups 和namespace 等Linux 内核特性来更好地隔离应用程序，并提供标准化的打包和部署方式。随着技术的不断发展，这种容器化技术逐渐演化为现在广泛使用的容器化平台，成为容器化技术的代表。

镜像(Image)、容器(Container) 和仓库(Repository)是Docker 的三大核心概念。镜像是一个只读的模板，用来创建Docker 容器[2]。镜像可以包含一个完整的操作系统环境，以及应用程序所需的所有依赖、配置等信息。Docker 镜像是构建和运行Docker 容器的基础。容器是从Docker 镜像创建的运行实例。每个容器都是相互独立的，有自己的文件系统、网络等资源。Docker 容器可以进行启动、停止、删除等操作[3]，容器之间也可以互相通信，实现应用程序的隔离和部署。仓库用于存储和分享Docker 镜像。Docker 官方提供了公共的Docker 仓库Docker Hub，用户可以在Docker Hub 上查找和下载各种开源的Docker 镜像。用户也可以自己搭建私有的Docker 仓库，用来存储和分享自己的镜像。通过使用Docker 镜像、容器和仓库，开发人员可以更方便地构建、部署和运行应用程序，同时也实现了更好的隔离性和可移植性。

在Docker 技术出现之前，通常的做法是使用传统的虚拟化技术，但这种技术在一些场景下存在不足，例如：

（1）虚拟化技术需要独立的操作系统，导致资源占用较大；

（2）启动虚拟机需要时间，导致启动速度慢；

（3）虚拟化技术不能很好地支持微服务架构。

Docker 通过利用Linux 内核的命名空间和控制组等功能，实现了轻量级的容器化技术。Docker 容器可以在相同的主机上运行多个相互独立的应用程序，每个容器都包含了应用程序及其所有依赖的软件包、库、配置文件等，实现了快速启动和资源隔离等功能。同时，Docker 还提供了统一的镜像格式和分发机制，使得应用程序在不同环境中的部署变得更加简单。

4 应用服务容器化部署

4.1 应用服务模块的拆分

在将应用服务部署到容器上之前，首先对现有业务系统的功能模块进行拆分，拆分的原则主要是遵循公益放映业务的合理性、业务特点和业务逻辑，可以按照用户动作，也可以根据业务资源结构等进行拆分。由于业务模块拆分的灵活性比较大，本次实践拆分主要遵循单一原则，一项服务做一项业务，服务之间的依赖关系尽可能小，便于后续的调整和维护。

本次容器化部署的应用服务模块主要包括影片的制版服务、授权服务、回传服务以及注册服务。影片制版服务负责影片视音频资源的封装、加密等制作任务，授权服务负责每一台放映设备的影片密钥制作任务，回传服务负责放映设备放映日志的收集和管理，注册服务负责放映设备注册信息的采集和管理。应用服务模块主要按照公益放映业务逻辑的先后顺序，同时结合用户使用的放映业务资源进行拆分，拆分可以根据业务需求的动态变化及时调整。

根据公益放映业务特点，将影片的发行版制版、日志回传以及播放器设备的注册等业务列为后台服务。同时对这些服务进行细化拆分，将编译好的应用程序和其对应依赖库打包生成独立的服务应用程序包。服务程序之间的通信采用消息队列方式实现。这样既响应了流程服务模块化分解的需求，也实现了服务流程各独立模块的衔接和贯通逻辑。

4.1.1 原系统应用服务逻辑

目前的数字电影公益放映服务平台开发建立时间较早，使用的还是互联网早期传统的开发架构和业务逻辑模式，并且因不断迭代升级致使系统功能繁杂，串行并行逻辑交织，任何一点出现的故障都将对整个业务系统的运行造成影响。目前的业务系统架构无法适应和满足未来所需的系统升级扩容需求（图1）。

图1 电影公益放映服务平台业务逻辑图

系统中的各个应用程序模块耦合程度比较高，要根据业务需求及公益放映不同的电影放映模式进行组合拆分调整，意味着所有关联的模块功能都要进行更新改造，而且都需要以停止服务的方式才能完成更新，无法做到系统不间断运行的服务保障能力。

4.1.2 容器化的应用服务逻辑

根据现有业务架构和流程逻辑特点，将部分应用程序进行服务功能模块拆分后进行容器化部署改造，有效降低了系统的耦合度，通过服务之间的组配，很快适应了多种新型放映模式的快速拆分整合。同时，容器化后的应用模块部署、更新、迭代都实现了在线实时更新，满足了业务的高可用性要求（图2）。

图2 电影公益放映系统容器服务架构图

容器化改造后，在服务中心前端添加了负载均衡代理，能有效降低高峰期业务系统的并行业务访问压力，同时通过后端Docker 容器的集群配置保障了系统的高可用性。在应用服务中心，将前端、后端和系统服务进行容器化模块的拆解，每一个模块不再依赖其它模块而独立运行，解决了旧系统因高耦合造成的改造复杂度问题。在存储区使用了缓存和数据库热备机制，增加读写速度的同时最大限度保证了数据库的高可用性。

4.2 构建并创建镜像

实现容器化改造，要创建Docker 镜像，通过镜像仓库获取公共镜像文件运行容器，也可以按照个性化的需求编写Dockerfile 创建自己的Docker 镜像文件，同时根据业务应用模块的需要搭建本地私有镜像仓库。以影片发行版制版服务镜像Dockerfile 为例，先部署Lib 包，再配置其环境变量。Dockerfile 编写完成后进行镜像构建工作。在构建中可以根据不同的软件版本给每个镜像设置不同的标签，便于在业务系统的运行中对容器进行管理和维护。如，可以通过执行“docker build”命令将Dockerfile 生成镜像。

4.3 Docker容器的运行与管理

实现容器化改造，可使用“docker run”命令运行容器，同时通过-v 参数挂载用户拆解的各个应用程序所需要的目录，实现Host 与容器之间的数据共享。通过数据卷（Volume）或绑定挂载（Bind Mount）可实现容器间数据共享。此外，使用Docker Swarm 模式可以将多个Docker 主机组合成一个虚拟的Docker 主机，从而提供负载均衡功能，实现业务均衡动态分配。在Docker Swarm 模式下，可以通过创建服务并指定副本数的方式实现其负载均衡。Docker Swarm会自动将该服务分配到可用的节点上，并使用内置的负载均衡算法将应用服务的请求分配到这些节点上。容器创建完成后，可以通过命令查看、管理容器，包括启动容器、停止容器、重启容器、删除容器、列出所有容器、进入容器、查看容器日志、显示容器使用的资源情况。

4.4 构建私有容器仓库

容器化改造，Docker 支持以默认模式将私有镜像上传到公有镜像仓库。本次我们使用Docker 默认的仓库是Docker Hub，出于数据安全性等方面考虑，私有化镜像部署在本地镜像仓库，一方面是出于对公益放映本地业务效率的考虑，这样的部署方式可以使镜像的创建效率更高；另一方面，根据目前互联网应用对数据安全的要求，这样的处理机制更有利于公益放映数据安全策略的实现。

Docker 提供私有化仓库的镜像包，使我们在本次公益放映发行版制版、授权回传、设备注册等业务服务部署实践中，实现快速部署一个本地私有化的镜像仓库。

5 性能比较分析

为了横向对比系统基础架构调整带来的性能提升，我们对使用Docker 封装部署的影片制版等应用服务进行了性能分析。本文采用Docker 自带镜像RabbitMQ 作为服务的消息中间件，对10 个数据量为5GB 左右的影片视频流进行逐帧加密并封装成发行版[4]的制版处理进行分析。系统部署的网络环境在千兆交换机连接的情况下进行，分别从部署速度、业务速度和数据库写入速度等方面进行性能分析。

5.1 部署速度

采用传统虚拟机的方式搭建影片制版服务，需要安装OpenSSL 等相关库的依赖包以及配置环境变量。即使一个有着多年经验的技术人员，根据个性化定制的需求逐步安装操作系统、软件环境、部署应用等，也需花费十几分钟。如果安装较为复杂的负载均衡等模块则需要以小时为单位。这次我们采用Docker 容器服务实现影片制版服务的搭建，达到了秒级的服务创建速度，每一个新的容器只需要修改配置文件内的地址即可，例如消息队列地址、接口地址等。本次采用同样的方式完成了制版及其他服务的部署，完成配置信息后，即可提供正常对外的应用模块业务服务，显著提升业务模块部署速度。

5.2 业务速度

我们分别通过在物理机服务器和Docker 容器对上述10个数据量为5GB 左右的影片视频流进行逐帧加密并封装成发行版的处理进行对比分析，测试完成时间。

物理服务器硬件环境：Intel(R) Xeon(R) CPU E7 4820v3@1.90GHz，32GB 内存，500GB 硬盘；软件环境：Ubuntu 18.04.6 LTS 64位操作系统。

Docker 容器环境部署在上述配置的同一台物理服务器上，分别错时进行测试，无时间交集以排除同时运行对性能的影响。

在物理机环境和Docker 容器分别启动制版服务，消息队列发送最大10 个请求，对10 部影片进行加密制版。为了有效对比，用同样的方法在物理机和Docker 容器中再进行多轮比对测试，平均值比对结果见表1。

表1 影片加密制版时间对比表

测试结果表明物理机和Docker 容器方式提供的影片加密制版服务在性能上没有明显差别，制版以外其他几个服务的测试情况同样验证了相同的结果。Docker 容器之间的网络通常会比物理机之间的网络更快。这是因为Docker 容器之间的通信可以直接在主机上进行，而不需要经过网络硬件设备的路由。Docker 的内存管理通常也比物理机更有效，因为Docker 可以限制每个容器所使用的内存量等资源。所以，在Docker 中运行多个应用程序时更容易控制内存使用情况。经过比对分析，Docker 在影片制版这项业务应用的整体性能表现与物理机相当。

5.3 数据库写入速度

在系统部署实践中，我们分别在物理服务器和容器中创建MySQL 数据库，参数配置相同，选取5 万条影片播放回传数据作为对象，通过查询表中的数据条数和起止时间对数据库的写入速度进行比对测试分析，测试共分3次以减少因为测试误差导致的影响，对比结果见表2。

表2 数据库写入时间对比表

从结果来看，物理机和容器方式的数据写入速度相差不大，正确率也均为100%。在查询速度方面，通过相同的SQL 语句分别在物理机和Docker 容器中运行的业务数据库查询，查询时间结果相差无几，因此在Docker 容器中部署数据库是可行的，部署的配置策略还会在后续的部署实践中进一步探索优化。

6 结论

本文通过实现Docker 技术在电影公益放映系统中的应用部署实践，成功将电影公益放映平台中的影片发行版加密制版、影片授权、影片回传等服务进行了模块化拆分，并根据业务逻辑实现了业务链在Docker 容器环境的部署。本次业务系统部署应用实践过程，证明容器化的部署方式，在满足相同性能指标的要求下，不仅可以大大降低应用服务的部署时间和复杂度，而且还能在多业务场景并发需求模式下，功能模块快速耦合、解耦以满足公益放映需求的目标。目前我们已经开展基于Docker 技术的生产系统建设，并逐步扩大Docker 的业务模块应用范围，以及不断优化容器性能，完善数据备份、运行维护等方面的功能，逐渐完成从传统物理机到容器的应用服务升级改造。