丁 鑫

中央宣傳部電影數(shù)字節(jié)目管理中心，北京 100866

1 引言

隨著公共文化的不斷發(fā)展，電影公益放映的場景模式在不斷增加。為了滿足多場景的放映需求，通過將電影公益放映系統(tǒng)中的影片訂購、制作、授權等相關應用服務模塊高效拆分和組合，來達到快速響應并適配新業(yè)務場景十分必要。在探索電影公益放映服務模式的過程中，通過Docker 容器技術在電影公益放映的系統(tǒng)建設部署實踐，實現(xiàn)對不同功能模塊的快速拆分、耦合，不但可以快速適配電影放映的不同場景，也是節(jié)省成本且靈活高效的解決方案。本文對Docker 容器部署電影發(fā)行版制版、場次回傳以及播放器設備注冊等服務部署實踐過程進行了總結。

2 電影公益放映系統(tǒng)的背景

2002 年，文化部、國家發(fā)展和改革委員會及國家廣播電影電視總局啟動了農(nóng)村電影放映“2131 工程”（即在21 世紀初實現(xiàn)“一村一月放映一場電影”），旨在豐富西部地區(qū)和老少邊貧地區(qū)農(nóng)民群眾的精神文化生活，解決農(nóng)民群眾看電影難的問題。電影數(shù)字節(jié)目管理中心（以下簡稱“中心”）正是為了承擔該計劃的職責和使命而成立的機構。中心于2006 年開發(fā)并上線了第一版集訂購、制作、注冊、授權、回傳等功能于一體的電影公益放映信息化平臺。

隨著時間的推移，電影公益放映系統(tǒng)不斷完善和發(fā)展，在農(nóng)村地區(qū)、城市社區(qū)、學校、醫(yī)院等公共場所得到了廣泛的應用。目前，電影公益放映系統(tǒng)已經(jīng)成為中國電影文化推廣的重要渠道之一，為廣大群眾提供了豐富多彩的電影文化體驗。但是，隨著時代與科技的進步，十多年前設計開發(fā)的平臺已經(jīng)凸顯了一些問題，主要有以下幾點：

（1）經(jīng)過多次的功能再升級，平臺功能模塊眾多，數(shù)據(jù)間交互錯綜復雜；

（2）系統(tǒng)設計初期只是為了服務于農(nóng)村公益電影放映這一單一場景，在當下要求放映場景多樣化的情況下，無法快速拆分耦合適應新的放映場景；

（3）使用的技術棧落后，舊代碼經(jīng)過十多年的更新迭代效率已經(jīng)十分低下；

（4）平臺底層架構一直為傳統(tǒng)信息化系統(tǒng)架構，后續(xù)的橫向縱向擴展都比較困難，無法滿足大數(shù)據(jù)量和計算量的需求。

針對這些亟待解決的問題，結合電影公益放映平臺的特點，我們認為通過重構平臺底層架構、引入容器和K8S 等技術棧的手段，升級改造出一個可以適應多放映場景的、模塊可以快速拆分耦合的、頁面設計現(xiàn)代化的、使用邏輯簡單方便且運行穩(wěn)定高效流暢的新電影公益放映信息化平臺十分必要。

本文基于以上目標，實踐了公益電影信息化平臺的制版、授權、回傳、注冊等模塊的容器化改造，并對改造后的幾個重要指標進行了對比，為后續(xù)全方面的容器化改造提供了參考依據(jù)。

3 Docker 容器技術

Docker 是一個開源的容器化平臺，其發(fā)展歷程可以追溯到2008 年[1]，Docker 的創(chuàng)始人Solomon Hykes 曾在法國創(chuàng)立了一家PaaS 公司dotCloud，專注于開發(fā)和部署Web 應用程序。該平臺采用了一種名為LXC（Linux Containers）的技術，可在單個Linux 操作系統(tǒng)實例中隔離應用程序。后來，該公司還使用了cgroups 和namespace 等Linux 內(nèi)核特性來更好地隔離應用程序，并提供標準化的打包和部署方式。隨著技術的不斷發(fā)展，這種容器化技術逐漸演化為現(xiàn)在廣泛使用的容器化平臺，成為容器化技術的代表。

鏡像(Image)、容器(Container) 和倉庫(Repository)是Docker 的三大核心概念。鏡像是一個只讀的模板，用來創(chuàng)建Docker 容器[2]。鏡像可以包含一個完整的操作系統(tǒng)環(huán)境，以及應用程序所需的所有依賴、配置等信息。Docker 鏡像是構建和運行Docker 容器的基礎。容器是從Docker 鏡像創(chuàng)建的運行實例。每個容器都是相互獨立的，有自己的文件系統(tǒng)、網(wǎng)絡等資源。Docker 容器可以進行啟動、停止、刪除等操作[3]，容器之間也可以互相通信，實現(xiàn)應用程序的隔離和部署。倉庫用于存儲和分享Docker 鏡像。Docker 官方提供了公共的Docker 倉庫Docker Hub，用戶可以在Docker Hub 上查找和下載各種開源的Docker 鏡像。用戶也可以自己搭建私有的Docker 倉庫，用來存儲和分享自己的鏡像。通過使用Docker 鏡像、容器和倉庫，開發(fā)人員可以更方便地構建、部署和運行應用程序，同時也實現(xiàn)了更好的隔離性和可移植性。

在Docker 技術出現(xiàn)之前，通常的做法是使用傳統(tǒng)的虛擬化技術，但這種技術在一些場景下存在不足，例如：

（1）虛擬化技術需要獨立的操作系統(tǒng)，導致資源占用較大；

（2）啟動虛擬機需要時間，導致啟動速度慢；

（3）虛擬化技術不能很好地支持微服務架構。

Docker 通過利用Linux 內(nèi)核的命名空間和控制組等功能，實現(xiàn)了輕量級的容器化技術。Docker 容器可以在相同的主機上運行多個相互獨立的應用程序，每個容器都包含了應用程序及其所有依賴的軟件包、庫、配置文件等，實現(xiàn)了快速啟動和資源隔離等功能。同時，Docker 還提供了統(tǒng)一的鏡像格式和分發(fā)機制，使得應用程序在不同環(huán)境中的部署變得更加簡單。

4 應用服務容器化部署

4.1 應用服務模塊的拆分

在將應用服務部署到容器上之前，首先對現(xiàn)有業(yè)務系統(tǒng)的功能模塊進行拆分，拆分的原則主要是遵循公益放映業(yè)務的合理性、業(yè)務特點和業(yè)務邏輯，可以按照用戶動作，也可以根據(jù)業(yè)務資源結構等進行拆分。由于業(yè)務模塊拆分的靈活性比較大，本次實踐拆分主要遵循單一原則，一項服務做一項業(yè)務，服務之間的依賴關系盡可能小，便于后續(xù)的調(diào)整和維護。

本次容器化部署的應用服務模塊主要包括影片的制版服務、授權服務、回傳服務以及注冊服務。影片制版服務負責影片視音頻資源的封裝、加密等制作任務，授權服務負責每一臺放映設備的影片密鑰制作任務，回傳服務負責放映設備放映日志的收集和管理，注冊服務負責放映設備注冊信息的采集和管理。應用服務模塊主要按照公益放映業(yè)務邏輯的先后順序，同時結合用戶使用的放映業(yè)務資源進行拆分，拆分可以根據(jù)業(yè)務需求的動態(tài)變化及時調(diào)整。

根據(jù)公益放映業(yè)務特點，將影片的發(fā)行版制版、日志回傳以及播放器設備的注冊等業(yè)務列為后臺服務。同時對這些服務進行細化拆分，將編譯好的應用程序和其對應依賴庫打包生成獨立的服務應用程序包。服務程序之間的通信采用消息隊列方式實現(xiàn)。這樣既響應了流程服務模塊化分解的需求，也實現(xiàn)了服務流程各獨立模塊的銜接和貫通邏輯。

4.1.1 原系統(tǒng)應用服務邏輯

目前的數(shù)字電影公益放映服務平臺開發(fā)建立時間較早，使用的還是互聯(lián)網(wǎng)早期傳統(tǒng)的開發(fā)架構和業(yè)務邏輯模式，并且因不斷迭代升級致使系統(tǒng)功能繁雜，串行并行邏輯交織，任何一點出現(xiàn)的故障都將對整個業(yè)務系統(tǒng)的運行造成影響。目前的業(yè)務系統(tǒng)架構無法適應和滿足未來所需的系統(tǒng)升級擴容需求（圖1）。

圖1 電影公益放映服務平臺業(yè)務邏輯圖

系統(tǒng)中的各個應用程序模塊耦合程度比較高，要根據(jù)業(yè)務需求及公益放映不同的電影放映模式進行組合拆分調(diào)整，意味著所有關聯(lián)的模塊功能都要進行更新改造，而且都需要以停止服務的方式才能完成更新，無法做到系統(tǒng)不間斷運行的服務保障能力。

4.1.2 容器化的應用服務邏輯

根據(jù)現(xiàn)有業(yè)務架構和流程邏輯特點，將部分應用程序進行服務功能模塊拆分后進行容器化部署改造，有效降低了系統(tǒng)的耦合度，通過服務之間的組配，很快適應了多種新型放映模式的快速拆分整合。同時，容器化后的應用模塊部署、更新、迭代都實現(xiàn)了在線實時更新，滿足了業(yè)務的高可用性要求（圖2）。

圖2 電影公益放映系統(tǒng)容器服務架構圖

容器化改造后，在服務中心前端添加了負載均衡代理，能有效降低高峰期業(yè)務系統(tǒng)的并行業(yè)務訪問壓力，同時通過后端Docker 容器的集群配置保障了系統(tǒng)的高可用性。在應用服務中心，將前端、后端和系統(tǒng)服務進行容器化模塊的拆解，每一個模塊不再依賴其它模塊而獨立運行，解決了舊系統(tǒng)因高耦合造成的改造復雜度問題。在存儲區(qū)使用了緩存和數(shù)據(jù)庫熱備機制，增加讀寫速度的同時最大限度保證了數(shù)據(jù)庫的高可用性。

4.2 構建并創(chuàng)建鏡像

實現(xiàn)容器化改造，要創(chuàng)建Docker 鏡像，通過鏡像倉庫獲取公共鏡像文件運行容器，也可以按照個性化的需求編寫Dockerfile 創(chuàng)建自己的Docker 鏡像文件，同時根據(jù)業(yè)務應用模塊的需要搭建本地私有鏡像倉庫。以影片發(fā)行版制版服務鏡像Dockerfile 為例，先部署Lib 包，再配置其環(huán)境變量。Dockerfile 編寫完成后進行鏡像構建工作。在構建中可以根據(jù)不同的軟件版本給每個鏡像設置不同的標簽，便于在業(yè)務系統(tǒng)的運行中對容器進行管理和維護。如，可以通過執(zhí)行“docker build”命令將Dockerfile 生成鏡像。

4.3 Docker容器的運行與管理

實現(xiàn)容器化改造，可使用“docker run”命令運行容器，同時通過-v 參數(shù)掛載用戶拆解的各個應用程序所需要的目錄，實現(xiàn)Host 與容器之間的數(shù)據(jù)共享。通過數(shù)據(jù)卷（Volume）或綁定掛載（Bind Mount）可實現(xiàn)容器間數(shù)據(jù)共享。此外，使用Docker Swarm 模式可以將多個Docker 主機組合成一個虛擬的Docker 主機，從而提供負載均衡功能，實現(xiàn)業(yè)務均衡動態(tài)分配。在Docker Swarm 模式下，可以通過創(chuàng)建服務并指定副本數(shù)的方式實現(xiàn)其負載均衡。Docker Swarm會自動將該服務分配到可用的節(jié)點上，并使用內(nèi)置的負載均衡算法將應用服務的請求分配到這些節(jié)點上。容器創(chuàng)建完成后，可以通過命令查看、管理容器，包括啟動容器、停止容器、重啟容器、刪除容器、列出所有容器、進入容器、查看容器日志、顯示容器使用的資源情況。

4.4 構建私有容器倉庫

容器化改造，Docker 支持以默認模式將私有鏡像上傳到公有鏡像倉庫。本次我們使用Docker 默認的倉庫是Docker Hub，出于數(shù)據(jù)安全性等方面考慮，私有化鏡像部署在本地鏡像倉庫，一方面是出于對公益放映本地業(yè)務效率的考慮，這樣的部署方式可以使鏡像的創(chuàng)建效率更高；另一方面，根據(jù)目前互聯(lián)網(wǎng)應用對數(shù)據(jù)安全的要求，這樣的處理機制更有利于公益放映數(shù)據(jù)安全策略的實現(xiàn)。

Docker 提供私有化倉庫的鏡像包，使我們在本次公益放映發(fā)行版制版、授權回傳、設備注冊等業(yè)務服務部署實踐中，實現(xiàn)快速部署一個本地私有化的鏡像倉庫。

5 性能比較分析

為了橫向?qū)Ρ认到y(tǒng)基礎架構調(diào)整帶來的性能提升，我們對使用Docker 封裝部署的影片制版等應用服務進行了性能分析。本文采用Docker 自帶鏡像RabbitMQ 作為服務的消息中間件，對10 個數(shù)據(jù)量為5GB 左右的影片視頻流進行逐幀加密并封裝成發(fā)行版[4]的制版處理進行分析。系統(tǒng)部署的網(wǎng)絡環(huán)境在千兆交換機連接的情況下進行，分別從部署速度、業(yè)務速度和數(shù)據(jù)庫寫入速度等方面進行性能分析。

5.1 部署速度

采用傳統(tǒng)虛擬機的方式搭建影片制版服務，需要安裝OpenSSL 等相關庫的依賴包以及配置環(huán)境變量。即使一個有著多年經(jīng)驗的技術人員，根據(jù)個性化定制的需求逐步安裝操作系統(tǒng)、軟件環(huán)境、部署應用等，也需花費十幾分鐘。如果安裝較為復雜的負載均衡等模塊則需要以小時為單位。這次我們采用Docker 容器服務實現(xiàn)影片制版服務的搭建，達到了秒級的服務創(chuàng)建速度，每一個新的容器只需要修改配置文件內(nèi)的地址即可，例如消息隊列地址、接口地址等。本次采用同樣的方式完成了制版及其他服務的部署，完成配置信息后，即可提供正常對外的應用模塊業(yè)務服務，顯著提升業(yè)務模塊部署速度。

5.2 業(yè)務速度

我們分別通過在物理機服務器和Docker 容器對上述10個數(shù)據(jù)量為5GB 左右的影片視頻流進行逐幀加密并封裝成發(fā)行版的處理進行對比分析，測試完成時間。

物理服務器硬件環(huán)境：Intel(R) Xeon(R) CPU E7 4820v3@1.90GHz，32GB 內(nèi)存，500GB 硬盤；軟件環(huán)境：Ubuntu 18.04.6 LTS 64位操作系統(tǒng)。

Docker 容器環(huán)境部署在上述配置的同一臺物理服務器上，分別錯時進行測試，無時間交集以排除同時運行對性能的影響。

在物理機環(huán)境和Docker 容器分別啟動制版服務，消息隊列發(fā)送最大10 個請求，對10 部影片進行加密制版。為了有效對比，用同樣的方法在物理機和Docker 容器中再進行多輪比對測試，平均值比對結果見表1。

表1 影片加密制版時間對比表

測試結果表明物理機和Docker 容器方式提供的影片加密制版服務在性能上沒有明顯差別，制版以外其他幾個服務的測試情況同樣驗證了相同的結果。Docker 容器之間的網(wǎng)絡通常會比物理機之間的網(wǎng)絡更快。這是因為Docker 容器之間的通信可以直接在主機上進行，而不需要經(jīng)過網(wǎng)絡硬件設備的路由。Docker 的內(nèi)存管理通常也比物理機更有效，因為Docker 可以限制每個容器所使用的內(nèi)存量等資源。所以，在Docker 中運行多個應用程序時更容易控制內(nèi)存使用情況。經(jīng)過比對分析，Docker 在影片制版這項業(yè)務應用的整體性能表現(xiàn)與物理機相當。

5.3 數(shù)據(jù)庫寫入速度

在系統(tǒng)部署實踐中，我們分別在物理服務器和容器中創(chuàng)建MySQL 數(shù)據(jù)庫，參數(shù)配置相同，選取5 萬條影片播放回傳數(shù)據(jù)作為對象，通過查詢表中的數(shù)據(jù)條數(shù)和起止時間對數(shù)據(jù)庫的寫入速度進行比對測試分析，測試共分3次以減少因為測試誤差導致的影響，對比結果見表2。

表2 數(shù)據(jù)庫寫入時間對比表

從結果來看，物理機和容器方式的數(shù)據(jù)寫入速度相差不大，正確率也均為100%。在查詢速度方面，通過相同的SQL 語句分別在物理機和Docker 容器中運行的業(yè)務數(shù)據(jù)庫查詢，查詢時間結果相差無幾，因此在Docker 容器中部署數(shù)據(jù)庫是可行的，部署的配置策略還會在后續(xù)的部署實踐中進一步探索優(yōu)化。

6 結論

本文通過實現(xiàn)Docker 技術在電影公益放映系統(tǒng)中的應用部署實踐，成功將電影公益放映平臺中的影片發(fā)行版加密制版、影片授權、影片回傳等服務進行了模塊化拆分，并根據(jù)業(yè)務邏輯實現(xiàn)了業(yè)務鏈在Docker 容器環(huán)境的部署。本次業(yè)務系統(tǒng)部署應用實踐過程，證明容器化的部署方式，在滿足相同性能指標的要求下，不僅可以大大降低應用服務的部署時間和復雜度，而且還能在多業(yè)務場景并發(fā)需求模式下，功能模塊快速耦合、解耦以滿足公益放映需求的目標。目前我們已經(jīng)開展基于Docker 技術的生產(chǎn)系統(tǒng)建設，并逐步擴大Docker 的業(yè)務模塊應用范圍，以及不斷優(yōu)化容器性能，完善數(shù)據(jù)備份、運行維護等方面的功能，逐漸完成從傳統(tǒng)物理機到容器的應用服務升級改造。