容器技術(shù)在電信支撐系統(tǒng)的應(yīng)用研究

朱明英，劉智瓊，池?zé)槼?/p>

（中國(guó)電信股份有限公司廣東研究院，廣州510630）

0 引言

隨著虛擬技術(shù)的發(fā)展，Docker 容器技術(shù)的出現(xiàn)給傳統(tǒng)的虛擬化帶來了很大的影響。不同于虛擬機(jī)的硬件虛擬化，容器采用的是基于操作系統(tǒng)層的虛擬化技術(shù)。由于Docker 容器使用公用的宿主OS 而不需要虛擬完整的GuestOS，使得容器的資源利用率遠(yuǎn)高于虛擬機(jī)。除了資源利用性能上的優(yōu)勢(shì)之外，容器最大的特點(diǎn)是可快速啟動(dòng)。容器啟動(dòng)速度在秒級(jí)，而虛擬機(jī)的啟動(dòng)速度在分鐘級(jí)別。

容器技術(shù)和虛擬機(jī)技術(shù)的比較如表1 所示。

1 電信支撐系統(tǒng)容器化改造分析

1.1 電信支撐系統(tǒng)存在問題分析

為順應(yīng)用戶規(guī)模與使用量劇增的趨勢(shì)和業(yè)務(wù)轉(zhuǎn)型的要求，傳統(tǒng)的電信支撐系統(tǒng)的架構(gòu)已經(jīng)不能滿足要求。

當(dāng)前電信支撐系統(tǒng)的架構(gòu)面臨的挑戰(zhàn)主要有：

（1）敏捷思想帶來新的業(yè)務(wù)交付模式導(dǎo)致版本變更迭代加快

隨著互聯(lián)網(wǎng)業(yè)務(wù)不斷發(fā)展，要求業(yè)務(wù)需求以最快速度響應(yīng)，迭代開發(fā)、向用戶交互高質(zhì)量的軟件產(chǎn)品成為IT 軟件行業(yè)的必然選擇。

電信支撐系統(tǒng)需要采用分布式架構(gòu)和容器化等技術(shù)，實(shí)現(xiàn)應(yīng)用和服務(wù)的自動(dòng)伸縮能力；基于微服務(wù)架構(gòu)，構(gòu)建統(tǒng)一、可重用的業(yè)務(wù)能力，實(shí)現(xiàn)對(duì)業(yè)務(wù)需求的快速響應(yīng)。

（2）單體應(yīng)用向微服務(wù)轉(zhuǎn)變，系統(tǒng)架構(gòu)云化對(duì)運(yùn)營(yíng)理念帶來了新的要求

系統(tǒng)架構(gòu)云化之后更加復(fù)雜，設(shè)備數(shù)量成倍數(shù)增長(zhǎng)，給運(yùn)維帶來很大的壓力和挑戰(zhàn)。在云化環(huán)境下IT資源高度虛擬化，加大整個(gè)架構(gòu)的復(fù)雜度，各種業(yè)務(wù)應(yīng)用、組件、虛擬機(jī)存在復(fù)雜的依賴關(guān)系，對(duì)系統(tǒng)監(jiān)控全面性要求更高，當(dāng)業(yè)務(wù)應(yīng)用出現(xiàn)故障時(shí)，問題的定位變得更加復(fù)雜，這些方面成為云化架構(gòu)下運(yùn)營(yíng)管理面臨的挑戰(zhàn)。

（3）互聯(lián)網(wǎng)帶來各種新技術(shù)和基礎(chǔ)框架導(dǎo)致組網(wǎng)復(fù)雜度劇變

在隨著云架構(gòu)，云部署的實(shí)施，尤其是應(yīng)用軟件SOA 化的轉(zhuǎn)型，應(yīng)用集群化、冗余部署、應(yīng)急、容災(zāi)等應(yīng)用組網(wǎng)越來越復(fù)雜。

而應(yīng)用容器化后帶來的環(huán)境一致性和標(biāo)準(zhǔn)化、容器輕量化、基于容器的快速交付、彈性伸縮正好可以解決這類挑戰(zhàn)。

為應(yīng)對(duì)上述挑戰(zhàn)，電信支撐系統(tǒng)需要采用“平臺(tái)+應(yīng)用”的模式，基于容器化技術(shù)，按業(yè)務(wù)聚合特征構(gòu)建云化的支撐系統(tǒng)，實(shí)現(xiàn)系統(tǒng)靈活可配置，應(yīng)用水平彈性可擴(kuò)展。

1.2 電信支撐系統(tǒng)容器化的優(yōu)勢(shì)

應(yīng)用容器化后，有以下幾個(gè)方面的優(yōu)勢(shì)：

（1）標(biāo)準(zhǔn)化

容器的運(yùn)行時(shí)引擎是標(biāo)準(zhǔn)化的，目前使用的都是基于OCI（Open Container Initiative，開放容器組織）的技術(shù)規(guī)范實(shí)現(xiàn)的運(yùn)行時(shí)引擎。

容器的鏡像也是標(biāo)準(zhǔn)化的，目前已有符合標(biāo)準(zhǔn)化的大量基礎(chǔ)鏡像，大大簡(jiǎn)化了從零構(gòu)建應(yīng)用鏡像的難度。應(yīng)用最終就是按鏡像標(biāo)準(zhǔn)制作成應(yīng)用鏡像，運(yùn)行在標(biāo)準(zhǔn)化的運(yùn)行時(shí)引擎上。

開發(fā)流程是標(biāo)準(zhǔn)化的，采用容器技術(shù)可以給所有項(xiàng)目成員快速復(fù)制出一套完全一致的開發(fā)環(huán)境，從而消除因開發(fā)環(huán)境不同導(dǎo)致的不一致性，降低軟件缺陷出現(xiàn)的概率。

部署流程是標(biāo)準(zhǔn)化的。傳統(tǒng)的部署模式下，為了保證發(fā)布的軟件包在其他機(jī)器上可正常安裝且運(yùn)行，一般需要在打包之前創(chuàng)建個(gè)干凈的環(huán)境，在這個(gè)干凈的環(huán)境下安裝各種依賴包，然后執(zhí)行打包腳本。測(cè)試軟件包時(shí)，又需要再創(chuàng)建一個(gè)干凈的環(huán)境安裝、運(yùn)行這個(gè)軟件包，非常繁瑣，并且容易漏掉依賴關(guān)系。容器化部署則從基礎(chǔ)鏡像開始（相當(dāng)于干凈的環(huán)境），添加應(yīng)用程序構(gòu)建應(yīng)用鏡像并部署，這個(gè)部署過程是自動(dòng)化的，所以，通過容器化部署可以快速完成應(yīng)用交付。

（2）版本控制

每一個(gè)容器的鏡像都有版本控制，這樣就可以追蹤不同版本的容器，監(jiān)控版本之間的差異。

傳統(tǒng)模式下應(yīng)用的升級(jí)，往往不僅僅是應(yīng)用軟件本身的升級(jí)，通常還會(huì)包含依賴項(xiàng)的升級(jí)。但新舊軟件的依賴項(xiàng)可能是不同的，甚至是有沖突的，所以在傳統(tǒng)的環(huán)境下做回滾一般比較困難。

如果使用容器技術(shù)，容器鏡像的版本內(nèi)集成了應(yīng)用的軟件環(huán)境的全部信息，這些復(fù)雜的環(huán)境集成后，標(biāo)記僅為一個(gè)版本，升級(jí)時(shí)先部署一個(gè)新的容器，看是否正常運(yùn)行。需要回滾時(shí)，把新的容器停掉，啟動(dòng)舊的容器即可完成回滾，整個(gè)過程在秒級(jí)完成，相對(duì)簡(jiǎn)單，版本切換也變得快捷，版本升級(jí)和灰度發(fā)布，在容器鏡像簡(jiǎn)單版本控制機(jī)制下，也變得較容易實(shí)現(xiàn)了。

（3）資源利用率高

容器與底層共享操作系統(tǒng)，性能優(yōu)良，系統(tǒng)負(fù)載低，在同等條件下可以運(yùn)行更多的應(yīng)用實(shí)例，更充分地利用系統(tǒng)資源。同時(shí)，容器擁有資源隔離與限制能力，可以精確地對(duì)應(yīng)用分配CPU、內(nèi)存等資源，保證了應(yīng)用間不會(huì)相互影響。

在傳統(tǒng)的基礎(chǔ)設(shè)施環(huán)境下，各業(yè)務(wù)需要的資源分配是分散管理的，各分散的業(yè)務(wù)部門通常按照規(guī)劃的最大額度申請(qǐng)物理機(jī)、虛擬機(jī)資源，這些資源即使空閑，也不能被別的業(yè)務(wù)部門使用，不能很好地解決資源共享和資源利用率的問題。

容器化方式下則是將業(yè)務(wù)應(yīng)用集中管理，所有應(yīng)用共享資源，各業(yè)務(wù)應(yīng)用原來獨(dú)占的資源都共享出來形成資源池，利用Linux 內(nèi)核的cgroup 機(jī)制，設(shè)置某個(gè)容器的資源配額，可以加大應(yīng)用在宿主機(jī)上的部署密度，提升資源利用率。

（4）應(yīng)用自動(dòng)化運(yùn)維

容器化應(yīng)用具有的高可用能力降低了運(yùn)維負(fù)擔(dān)，容器管理的集群架構(gòu)，多節(jié)點(diǎn)資源冗余設(shè)計(jì)，保證應(yīng)用在單節(jié)點(diǎn)出現(xiàn)故障時(shí)仍然可用。

應(yīng)用容器化后，支持彈性伸縮，避免了傳統(tǒng)的擴(kuò)容、部署、測(cè)試等繁瑣流程，減少了大量運(yùn)維的工作量。

容器化后完善的日志和監(jiān)控簡(jiǎn)化了運(yùn)維的工作，大量的自動(dòng)告警技術(shù)和簡(jiǎn)單易用的運(yùn)維界面，實(shí)現(xiàn)了傳統(tǒng)模式難于實(shí)現(xiàn)的自動(dòng)化運(yùn)維。

（5）持續(xù)部署與測(cè)試

在傳統(tǒng)模式下，上線之前要把代碼提交到版本倉庫，進(jìn)行構(gòu)建，再發(fā)布到測(cè)試環(huán)境測(cè)試，之后發(fā)布到生產(chǎn)環(huán)境預(yù)測(cè)試，才能上線。這是典型的一個(gè)版本上線流程，其中的測(cè)試環(huán)境、預(yù)生產(chǎn)環(huán)境、生產(chǎn)環(huán)境之間有一定的差異，也存在一定的兼容性問題。

容器化后，依賴環(huán)境都集成到鏡像中，測(cè)試環(huán)境和生產(chǎn)環(huán)境保持一致，通過容器化后的持續(xù)部署與測(cè)試流程，能全流程管控產(chǎn)品，達(dá)到快速開發(fā)、集成和發(fā)布的目標(biāo)，提高了產(chǎn)品的快速交付能力。

2 電信支撐系統(tǒng)容器化改造實(shí)施方案

2.1 容器化改造的適用范圍

電信支撐系統(tǒng)通過云化改造后，絕大多數(shù)應(yīng)用都適合部署成容器應(yīng)用。這些應(yīng)用可以分為有狀態(tài)應(yīng)用和無狀態(tài)應(yīng)用。應(yīng)用的有狀態(tài)和無狀態(tài)是根據(jù)應(yīng)用是否有持久化保存數(shù)據(jù)的需求而言的，即持久化保存數(shù)據(jù)的應(yīng)用為有狀態(tài)的應(yīng)用，反之則為無狀態(tài)的應(yīng)用。

（1）有狀態(tài)應(yīng)用

有狀態(tài)應(yīng)用需要持久化保存數(shù)據(jù)；一般是數(shù)據(jù)類服務(wù)，如集群協(xié)調(diào)服務(wù)、日志分析等。Kubernetes 提供了持久化數(shù)據(jù)卷（Persistent Volume）的功能，可以實(shí)現(xiàn)數(shù)據(jù)的持久化保存，從而支持有狀態(tài)應(yīng)用容器化。

容器化的有狀態(tài)應(yīng)用由于其應(yīng)用特性，所以不可隨意啟動(dòng)、停止實(shí)例，不可隨意增加、刪除實(shí)例；服務(wù)實(shí)例發(fā)生故障后，需要立即進(jìn)行維護(hù)以防止數(shù)據(jù)丟失和損壞。

雖然有狀態(tài)應(yīng)用有這些限制，但仍然可以發(fā)揮容器化的下列優(yōu)勢(shì)：

●容器方式部署和管理應(yīng)用的能力

●利用容器一致性交付優(yōu)勢(shì)

●實(shí)現(xiàn)快速部署和統(tǒng)一管理

（2）無狀態(tài)應(yīng)用

無狀態(tài)應(yīng)用對(duì)單次請(qǐng)求的處理不依賴其他請(qǐng)求，服務(wù)本身不存儲(chǔ)任何信息。無狀態(tài)容器化應(yīng)用有以下特點(diǎn)：數(shù)據(jù)不落盤，或者只有臨時(shí)數(shù)據(jù)落盤；可以隨意啟動(dòng)、停止和增加、刪除實(shí)例；應(yīng)用實(shí)例發(fā)生故障后，可以立即刪除并通過模板創(chuàng)建新實(shí)例取而代之。

無狀態(tài)應(yīng)用可以發(fā)揮容器的以下優(yōu)勢(shì)：

●發(fā)揮容器方式部署和管理應(yīng)用的能力

●利用容器一致性交付優(yōu)勢(shì)

●實(shí)現(xiàn)快速部署和統(tǒng)一管理

●可運(yùn)行在Kubernetes 提供的容器集群上

●由Kubernetes 提供高可靠、故障容忍、彈性伸縮、資源調(diào)度等功能

（3）不適合容器化改造的應(yīng)用

如果應(yīng)用有如下特點(diǎn)，不適合直接容器化，需要進(jìn)行改造。

①使用大型中間件的應(yīng)用

大型中間件主要是指如WebLogic、WebSphere、IBM MQ 等，這些中間件功能豐富，但是安裝配置復(fù)雜，資源占用率高，代碼不開源，進(jìn)行容器化改造困難較大（因?yàn)殚]源產(chǎn)品需要依賴閉源廠商對(duì)中間件進(jìn)行容器化改造），這些都與容器輕量化的理念不符合。

②需要部署在一個(gè)操作系統(tǒng)中的多個(gè)強(qiáng)耦合應(yīng)用

容器適用于運(yùn)行單個(gè)應(yīng)用，如果一個(gè)容器中運(yùn)行多個(gè)應(yīng)用，管理每個(gè)應(yīng)用進(jìn)程、存取日志、升級(jí)應(yīng)用的時(shí)候就會(huì)很復(fù)雜。

③涉及內(nèi)核操作的應(yīng)用

容器本身是一個(gè)受到諸多管控的進(jìn)程，隔離并不完全徹底，如果應(yīng)用涉及到內(nèi)核的操作，如自定義了驅(qū)動(dòng)、內(nèi)核模塊，可能導(dǎo)致宿主系統(tǒng)異常進(jìn)而影響到其他容器應(yīng)用異常。

④存儲(chǔ)了海量數(shù)據(jù)的數(shù)據(jù)庫

存儲(chǔ)了海量數(shù)據(jù)的數(shù)據(jù)庫對(duì)I/O 的要求高、網(wǎng)絡(luò)吞吐量高，這些要求容器還不能很好滿足。而容器的優(yōu)勢(shì)如易于構(gòu)建、彈性伸縮、維護(hù)環(huán)境一致性對(duì)于海量數(shù)據(jù)庫意義不大。

2.2 容器化改造的關(guān)鍵點(diǎn)

電信支撐系統(tǒng)容器化改造的關(guān)鍵點(diǎn)，主要包括如下方面：

（1）引入分布式框架

分布式服務(wù)治理框架可以加速系統(tǒng)微服務(wù)化的改造，并標(biāo)準(zhǔn)化開發(fā)過程，便于測(cè)試、部署。通過引入Dubbo 或Spring Cloud 等分布式服務(wù)治理框架，將應(yīng)用微服務(wù)化，提升系統(tǒng)可擴(kuò)展性和持續(xù)交付能力，實(shí)現(xiàn)系統(tǒng)的高可用。

（2）組件云化

推進(jìn)“去IOE”，促進(jìn)IT 系統(tǒng)x86 化，引入分布式數(shù)據(jù)庫、分布式緩存、分布式消息中間件等組件，極大提升系統(tǒng)彈性伸縮能力，降低系統(tǒng)負(fù)載壓力。

（3）應(yīng)用與數(shù)據(jù)分離

通過將業(yè)務(wù)實(shí)現(xiàn)和業(yè)務(wù)數(shù)據(jù)進(jìn)行分離，將業(yè)務(wù)數(shù)據(jù)實(shí)現(xiàn)無狀態(tài)化，前端業(yè)務(wù)通過統(tǒng)一的數(shù)據(jù)訪問引擎進(jìn)行路由，可以極大的降低業(yè)務(wù)數(shù)據(jù)的安全風(fēng)險(xiǎn)；

（4）應(yīng)用容器化改造

應(yīng)用在容器化改造前，需要了解應(yīng)用的運(yùn)行環(huán)境、依賴包等，并且熟悉應(yīng)用的部署形態(tài)。

①執(zhí)行項(xiàng)目遷移：將應(yīng)用工程遷移到容器化工程中進(jìn)行管理。

②構(gòu)建容器化環(huán)境：按運(yùn)行環(huán)境和依賴包選擇基礎(chǔ)鏡像，按標(biāo)準(zhǔn)編寫Dockerfile。

③容器鏡像生成：在容器化工程中執(zhí)行自動(dòng)構(gòu)建生產(chǎn)容器鏡像，完成容器化改造，統(tǒng)一交付鏡像。

④配置與應(yīng)用分離：將應(yīng)用的配置信息通過環(huán)境變量注入，或者通過從配置中心拉取配置的方式，來保障應(yīng)用和配置分離。

3 結(jié)語

本文通過對(duì)容器技術(shù)的研究，結(jié)合目前電信支撐系統(tǒng)的現(xiàn)狀，提出了利用容器技術(shù)解決電信支撐系統(tǒng)架構(gòu)存在的問題，并對(duì)容器化改造后的優(yōu)勢(shì)進(jìn)行了分析。最后，給出了電信支撐系統(tǒng)容器化改造的適用范圍和改造關(guān)鍵點(diǎn)，為電信支撐系統(tǒng)架構(gòu)的后續(xù)優(yōu)化升級(jí)提供了借鑒意義。