王穎 鄒一榮 吳家隱

摘? 要：隨著通信業(yè)務(wù)的快速發(fā)展，運營商早已著眼于建立以客戶為核心，以取得高質(zhì)量的客戶忠誠度為目標(biāo)的企業(yè)發(fā)展策略。本課題的研究基于OpenStack架構(gòu)設(shè)計，并實現(xiàn)對容器化改造后的運營商業(yè)務(wù)系統(tǒng)的容器管理系統(tǒng)的搭建。本課題主要采用OpenStack架構(gòu)，搭建Kubernetes集群，采用Docker技術(shù)實現(xiàn)容器化改造，從而滿足運營商對突發(fā)訪問量的業(yè)務(wù)需求。容器化是一種輕量級的虛擬化方案。該方案不需要修改業(yè)務(wù)系統(tǒng)核心，主要通過Linux內(nèi)核的功能進(jìn)行虛擬化，使所有容器在同一內(nèi)核中運行。本文的容器化試點應(yīng)用系統(tǒng)是廣東聯(lián)通手機(jī)營業(yè)廳，為廣東聯(lián)通客戶提供查詢、處理、營銷等快速自助客戶端軟件。

關(guān)鍵詞：運營商業(yè)務(wù)系統(tǒng);OpenStack;Kubernetes;容器化;容器管理系統(tǒng)

中圖分類號：TP393.09? ? ? 文獻(xiàn)標(biāo)識碼：A 文章編號：2096-4706（2019）20-0001-07

Abstract：With the rapid development of telecommunication business，operators have already begun to focus on establishing enterprise development strategies with customers as the core and high quality customer loyalty as the goal. The purpose of this research is to design and implement the container management system of the operators business system after container transformation based on OpenStack architecture. This topic mainly adopts OpenStack architecture，builds Kubernetes cluster，and adopts Docker technology to realize container transformation，so as to meet the business needs of operators for sudden traffic. Containerization is a lightweight virtualization scheme. This solution does not need to modify the business system core，mainly through the function of the Linux kernel to virtualize，so that all containers run in the same kernel. The container pilot application system in this paper is the mobile phone business hall of Guangdong Unicom，which provides fast self-service client software such as inquiry，processing and marketing for Guangdong Unicom customers.

Keywords：operator business system;Openstack;Kubernetes;containerization;container management system

0? 引? 言

本文的研究內(nèi)容包括以下三個方面：第一，從實際情況出發(fā)，提出從三個方面對原運營商業(yè)務(wù)系統(tǒng)進(jìn)行應(yīng)用改造，以及測試改造后的應(yīng)用是否適應(yīng)容器化部署;第二，分析多種容器化技術(shù)的優(yōu)缺點，結(jié)合實際的運營商業(yè)務(wù)系統(tǒng)，從不同方案中選擇合理且高效的容器化部署方案;第三，根據(jù)容器化部署方案，設(shè)計相應(yīng)的容器管理系統(tǒng)ECP系統(tǒng)。

確認(rèn)容器化改造效果，并順利進(jìn)行容器化部署工作，為基于容器化改造后的運營商業(yè)務(wù)系統(tǒng)開發(fā)出一個功能完整的容器管理系統(tǒng)，經(jīng)測試該管理系統(tǒng)具有有效性。最后進(jìn)行了全文總結(jié)，并對未來的研究做出展望。

1? 緒論

1.1? 課題背景及研究意義

隨著通信業(yè)務(wù)的迅速發(fā)展，運營商早已著眼于建立以客戶為核心，以取得高質(zhì)量的客戶忠誠度為目標(biāo)的企業(yè)發(fā)展策略。目前，中國電信業(yè)的競爭方向發(fā)生了巨大變化。從價格競爭到服務(wù)競爭，服務(wù)已悄然成為影響競爭格局的主導(dǎo)因素。渠道是企業(yè)與客戶溝通、完成產(chǎn)品和服務(wù)交流、對業(yè)務(wù)貢獻(xiàn)的重要載體。其為客戶和競爭對手提供市場信息，為雙方交易提供便利，有效緩解供需矛盾。它也提供了符合用戶需求的產(chǎn)品和服務(wù)，向客戶傳遞產(chǎn)品和服務(wù)信息，實現(xiàn)市場以及服務(wù)目標(biāo)。與此同時，互聯(lián)網(wǎng)業(yè)務(wù)規(guī)模以及突發(fā)式的訪問量的激增也成為常態(tài)。

隨著運營商的業(yè)務(wù)能力的開放和業(yè)務(wù)互聯(lián)網(wǎng)化，某些業(yè)務(wù)的波峰波谷現(xiàn)象也更加突出。本課題的研究基于OpenStack架構(gòu)設(shè)計，并實現(xiàn)對容器化改造后的運營商業(yè)務(wù)系統(tǒng)的容器管理系統(tǒng)。為進(jìn)一步滿足運營商對突發(fā)訪問量的業(yè)務(wù)需求，本課題主要依據(jù)OpenStack架構(gòu)，建立了Kubernetes集群，并利用Docker技術(shù)實現(xiàn)了容器化改造。該方案使企業(yè)增加擁有200萬注冊用戶，并滿足100到50萬用戶并發(fā)訪問的實際需求。在此基礎(chǔ)上，研究容器化技術(shù)在業(yè)務(wù)支撐系統(tǒng)中的可應(yīng)用場景;評估試點容器化技術(shù)相關(guān)開源產(chǎn)品的特性和成熟度;評估試點容器化遷移的可能性;完成不同部署和資源調(diào)度管理方案的差異分析;研究容器化改造后系統(tǒng)運營、運行維護(hù)及安全管控的實際問題。

1.2? 運營商業(yè)務(wù)系統(tǒng)發(fā)展現(xiàn)狀

為了促進(jìn)服務(wù)質(zhì)量的提升，提高客戶滿意度和粘度，降低人工負(fù)荷壓力，滿足運維人員的日常經(jīng)營需要，需要分析運營商的當(dāng)前業(yè)務(wù)。運營商手機(jī)營業(yè)廳業(yè)務(wù)存在以下問題。

首先，現(xiàn)存的資源靜態(tài)配置模式以單個應(yīng)用為單位，因此無法實現(xiàn)跨應(yīng)用的資源共享和動態(tài)調(diào)度，從而無法支撐應(yīng)用快速擴(kuò)容。也因此，應(yīng)以天為單位來計算物理機(jī)的部署時間，以小時為單位來計算虛擬機(jī)的部署時間;其次，應(yīng)用環(huán)境獨立安裝，無法自動擴(kuò)展，中間件、數(shù)據(jù)庫等運行環(huán)境需要分別部署，導(dǎo)致資源分配完畢后，仍無法快速使用;最后，資源獨占，無法多應(yīng)用共享?，F(xiàn)有的靜態(tài)配置模式應(yīng)用環(huán)境需獨立安裝，無法自動擴(kuò)展，應(yīng)用及其依賴的操作系統(tǒng)、中間件、數(shù)據(jù)庫等運行環(huán)境都是分別部署，這將導(dǎo)致資源分配好后，仍無法快速使用應(yīng)用;最后，應(yīng)用部署周期長，在資源充足且不考慮審批時間的前提下，目前從資源申請、應(yīng)用申請、應(yīng)用部署到生產(chǎn)環(huán)境（不含開發(fā)過程），這將需要一周的時間，如此效率根本無法滿足快速啟動業(yè)務(wù)的要求。帶狀態(tài)的應(yīng)用無法自動加載和快速迭代，只能從現(xiàn)有的應(yīng)用需要綁定內(nèi)存和從數(shù)據(jù)庫中獲取狀態(tài)信息，從而導(dǎo)致無法快速、自動注冊到業(yè)務(wù)集群中，因此也無法自動進(jìn)行業(yè)務(wù)分流，需手工配置，暫停業(yè)務(wù)后再上線。與此同時，現(xiàn)有的應(yīng)用程序體系結(jié)構(gòu)的任何更改都需要二次編譯、集成、測試和部署整個應(yīng)用程序，這將導(dǎo)致運營商業(yè)務(wù)系統(tǒng)的體積持續(xù)擴(kuò)張，隨之帶來的影響是交付時間和反饋周期的延長，這無疑會在很大程度上影響業(yè)務(wù)上線速度。

1.3? 本文研究思路及主要內(nèi)容

本文主要研究目標(biāo)是運營商業(yè)務(wù)系統(tǒng)容器化及其管理工作。因此，研究內(nèi)容主要包括以下三個方面。

首先，分析現(xiàn)有的某運營商業(yè)務(wù)系統(tǒng)，為運營商業(yè)務(wù)系統(tǒng)的容器化提供技術(shù)支撐。本課題根據(jù)實際情況，提出從三個方面改造現(xiàn)有的運營商業(yè)務(wù)應(yīng)用系統(tǒng)，使其適應(yīng)容器化改造;其次，基于OpenStack架構(gòu)構(gòu)建Kubernetes集群方案，采用Docker技術(shù)對運營商業(yè)務(wù)系統(tǒng)進(jìn)行容器化改造。該方案結(jié)合了OpenStack架構(gòu)和Kubernetes集群，使得云計算平臺機(jī)動性更好，同時高效利用了物理機(jī)、網(wǎng)絡(luò)以及存儲等資源。應(yīng)用使用Docker技術(shù)，將其部署在Kubernetes集群上，充分提升了開發(fā)人員的開發(fā)效率，大幅度降低了運維人員的維護(hù)成本;最后，設(shè)計出一個基于容器化改造后的運營商業(yè)務(wù)系統(tǒng)的容器管理系統(tǒng)，對平臺內(nèi)部的容器實例開展管理工作。本課題設(shè)計的容器管理系統(tǒng)可以為現(xiàn)有運營商業(yè)務(wù)提供有效的編排服務(wù)，更加充分地利用容器資源，提高資源利用率。

OpenStack、Docker技術(shù)、云計算等均是近幾年的新興技術(shù)，相關(guān)技術(shù)仍處于不斷的發(fā)展變化中。因此業(yè)界尚沒有成熟的運營商級的網(wǎng)絡(luò)部署案例可作參考。綜上所述，本課題在實施的過程中仍面臨一定的挑戰(zhàn)。

第一，從實際情況出發(fā)，提出從三個方面對原運營商業(yè)務(wù)系統(tǒng)進(jìn)行應(yīng)用改造，測試改造后的應(yīng)用是否適應(yīng)容器化部署;

第二，分析多種容器化技術(shù)的優(yōu)缺點，結(jié)合實際的運營商業(yè)務(wù)系統(tǒng)，從不同方案中選擇合理且高效的容器化部署方案;

第三，根據(jù)容器化部署方案，設(shè)計相應(yīng)的容器管理系統(tǒng)ECP系統(tǒng)。本課題提出的ECP系統(tǒng)主要分為七個模塊，分別對容器管理系統(tǒng)相關(guān)業(yè)務(wù)進(jìn)行管理。

2? 容器化改造及部署方案

2.1? 應(yīng)用的無狀態(tài)改造

一般而言，狀態(tài)分為三個過程，即分發(fā)、處理和存儲。有狀態(tài)服務(wù)是指在任何時候都可以備份服務(wù)實例的一部分?jǐn)?shù)據(jù)。為實現(xiàn)數(shù)據(jù)持久化功能，在創(chuàng)建新的服務(wù)時，可以恢復(fù)備份數(shù)據(jù)。有狀態(tài)服務(wù)不支持自動服務(wù)容量調(diào)節(jié)，即該服務(wù)僅擁有一個實例;而無狀態(tài)服務(wù)是指服務(wù)運行的實例無需備份，這是為了在請求相同的情況下，任意實例對其響應(yīng)結(jié)果是完全一致的。本文選擇將應(yīng)用改造為無狀態(tài)，實現(xiàn)無狀態(tài)后，集群的所有狀態(tài)都可以聚集在一起，便于跨機(jī)房部署，實現(xiàn)跨機(jī)房的高可用性。無狀態(tài)化后，實施容器化就會十分順暢。

如果應(yīng)用程序在PaaS平臺上動態(tài)擴(kuò)展，則需要對應(yīng)用程序進(jìn)行無狀態(tài)化改造。以手機(jī)APP架構(gòu)為例，Web層負(fù)責(zé)向用戶呈現(xiàn)內(nèi)容，APP層負(fù)責(zé)處理業(yè)務(wù)邏輯和數(shù)據(jù)庫交互工作。Web層使用負(fù)載平衡進(jìn)行請求分發(fā)，而APP層的Web層以多種方式調(diào)用。

因此，應(yīng)用的無狀態(tài)化改造需要分為Web層應(yīng)用的無狀態(tài)改造和APP層應(yīng)用的無狀態(tài)改造，如圖1所示。

2.1.1? Web層應(yīng)用的無狀態(tài)改造

首先，Web層應(yīng)用需要去Http Session，即不再使用傳統(tǒng)的http會話作為會話保持的方案;其次，采用http與JSON相結(jié)合的方式作為客戶端與Web端的交互手段;最后，使用緩存服務(wù)器為用戶存儲會話信息。改造后的結(jié)構(gòu)如圖2所示。

通過上述改造，現(xiàn)存的應(yīng)用系統(tǒng)完全能夠達(dá)成應(yīng)用的狀態(tài)數(shù)據(jù)與應(yīng)用成功分離的目的，Web實例的啟動和停止都不會導(dǎo)致用戶會話數(shù)據(jù)的丟失。

2.1.2? APP層應(yīng)用的無狀態(tài)改造

APP層需要支持動態(tài)收縮，這不僅取決于APP層的無狀態(tài)實現(xiàn)，還取決于從Web層到APP層的RPC調(diào)用模式。ZooKeeper保存應(yīng)用實例的實時分布數(shù)據(jù)，平臺監(jiān)控應(yīng)用實例的運行狀態(tài)。當(dāng)狀態(tài)發(fā)生變化時，通知ZooKeeper修改應(yīng)用實例的分布數(shù)據(jù)。Web層根據(jù)分組策略獲取一組應(yīng)用實例的分布信息，并根據(jù)該信息對調(diào)用組中的應(yīng)用實例進(jìn)行輪詢。

2.2? 配置中心化改造

在分布式環(huán)境中的大多數(shù)情況下，同一類型的服務(wù)將有許多實例部署在其上。待部署的實例利用某些固定的配置方式。為了高效運用及維護(hù)這些變化極少的配置方案，配置管理服務(wù)應(yīng)運而生。絕大部分的服務(wù)實例配置問題都可以通過該服務(wù)得到便捷的管理。統(tǒng)一配置系統(tǒng)為應(yīng)用系統(tǒng)提供配置獲取服務(wù)。該應(yīng)用程序不僅可以在啟動時從統(tǒng)一配置系統(tǒng)獲取相關(guān)配置，而且支持對感知運行狀態(tài)下配置數(shù)據(jù)的變化的感知。隨后，該配置系統(tǒng)將獲得更改后的配置數(shù)據(jù)。

ADConf統(tǒng)一配置系統(tǒng)是一個用于管理持久配置的系統(tǒng)，具有簡單、可靠、易于使用等優(yōu)勢。簡單性是指整體結(jié)構(gòu)十分簡單，這就有效降低了錯誤概率?？煽啃砸馕吨鴳?yīng)用程序應(yīng)該在任何情況下都能使用。易用性是指客戶端的接口十分簡單，方便開發(fā)人員的理解和使用。本文提出配置中心化改造方案，ADConf總體架構(gòu)圖如圖3所示。

ADConf作為配置中心，將統(tǒng)一配置系統(tǒng)的功能分為發(fā)布和訂閱兩部分。統(tǒng)一配置系統(tǒng)存儲持久化數(shù)據(jù)，這些數(shù)據(jù)的變化頻率很低，因此發(fā)布采用手工配置的形式，并通過統(tǒng)一配置系統(tǒng)的后臺管理接口發(fā)布，訂閱是統(tǒng)一配置系統(tǒng)的核心功能。訂閱由統(tǒng)一配置系統(tǒng)客戶端API執(zhí)行。

統(tǒng)一配置系統(tǒng)服務(wù)端以MySQL與本地文件相結(jié)合的形式存放配置數(shù)據(jù)。發(fā)布數(shù)據(jù)時，先將數(shù)據(jù)寫入數(shù)據(jù)庫，然后寫入本地文件;訂閱數(shù)據(jù)時，不需要查詢數(shù)據(jù)庫，直接從本地文件獲取數(shù)據(jù)即可，這樣可以最大限度地減少數(shù)據(jù)庫的壓力。

統(tǒng)一配置系統(tǒng)服務(wù)端實際上是同一個集群，集群中的任何機(jī)器都連接到同一個MySQL數(shù)據(jù)庫。同時，集群間的數(shù)據(jù)同步有兩種方式：一是每臺服務(wù)器定期去MySQL將數(shù)據(jù)轉(zhuǎn)儲到本地文件;二是一臺服務(wù)器負(fù)責(zé)接收數(shù)據(jù)發(fā)布請求，當(dāng)MySQL和本地文件同步數(shù)據(jù)完成后，將HTTP請求（通知）發(fā)送到其他幾個服務(wù)器，待其他服務(wù)器收到通知后，將MySQL內(nèi)剛剛更新的數(shù)據(jù)轉(zhuǎn)儲到本地文件。同時，每臺服務(wù)器前端都需要配置相對應(yīng)的Nginx來做流量控制。

2.3? 日志中心化改造

互聯(lián)網(wǎng)系統(tǒng)在運行和運營的過程中產(chǎn)生了大量的日志。因此，日志的處理能力是Internet應(yīng)用系統(tǒng)必須具備的關(guān)鍵能力之一。處理系統(tǒng)產(chǎn)生的大量日志主要依靠采集日志和分析技術(shù)。Logstash是一個完全開源的分布式海量日志聚合系統(tǒng)，以其可靠性和高可用性受到用戶的青睞。Logstash支持在系統(tǒng)中定制各類數(shù)據(jù)發(fā)送方。Logstash收集和分析日志，這些日志也可以存儲和重用。Logstash支持系統(tǒng)日志、Web Server日志、錯誤日志和應(yīng)用日志。同時Logstash還有一個用于搜索和顯示所有日志的Web界面。

Kibana也是一個開源和免費的工具，用于總結(jié)、分析和搜索重要的數(shù)據(jù)日志，并提供方便用戶使用的操作接口，也可用于Logstash和ElasticSearch的日志分析的Web界面。本文提出的日志中心化改造后架構(gòu)如圖4所示。

日志系統(tǒng)的具體工作流程：Logstash agent負(fù)責(zé)監(jiān)控并過濾日志，過濾后的日志內(nèi)容將被發(fā)送給Redis（此處的Redis只處理隊列不做存儲）;Logstash index收集日志并將其提供給全文搜索服務(wù);ElasticSearch搜索用于自定義搜索;Kibana用于頁面顯示和自定義搜索。

2.4? 容器化系統(tǒng)架構(gòu)

當(dāng)前運營商手機(jī)營業(yè)廳系統(tǒng)的總體架構(gòu)包括業(yè)務(wù)展現(xiàn)層（SaaS）、能力運營層（OPaaS）、業(yè)務(wù)能力層（APaaS）、技術(shù)平臺層（IPaaS）和基礎(chǔ)設(shè)施層（IaaS）。以此為基礎(chǔ)提出的容器化后的系統(tǒng)架構(gòu)如圖5所示。

每一個RC（代表一個受Replication Controller控制的集群，可以在RC的控制下完成這個集群的彈性伸縮）。接入層使用硬件防火墻對外。Nginx集群容器化后作為服務(wù)接入負(fù)載均衡，每個Nginx獨立部署于一個Pod之上，不做擴(kuò)縮容，出現(xiàn)問題手工維護(hù);Redis等容器化后注冊為緩存服務(wù)保存服務(wù)Session等信息;業(yè)務(wù)Web層容器化后以Pod形式部署，通過RC控制擴(kuò)容、縮容;不同的Nginx對應(yīng)不同組的Web集群。Web層彈性服務(wù)的發(fā)現(xiàn)由PAAS平臺Service機(jī)制來完成，Nginx服務(wù)需要分發(fā)到Service上去。

Zookeeper作為服務(wù)連接到Kubernetes集群。Web層APP作為服務(wù)消費者注冊到Zookeeper（使用Dubbo客戶端Jar），采用RPC協(xié)議動態(tài)連接各種微服務(wù)APP。各種微服務(wù)APP使用Dubbo服務(wù)端（Jar）連接Zookeeper注冊服務(wù)實例。

最終整個平臺運行于IPaaS平臺之上。目前IPaaS平臺構(gòu)建的主流容器技術(shù)基于Docker和容器管理系統(tǒng)。

3? 基于OpenStack的容器管理系統(tǒng)總體設(shè)計

3.1? 總體架構(gòu)設(shè)計

根據(jù)需求分析情況，再結(jié)合OpenStack和Kubernetes這兩大開源項目，設(shè)計出相應(yīng)容器管理系統(tǒng)的架構(gòu)。容器管理系統(tǒng)整體由五部分組成，其整體架構(gòu)如圖6所示。

（1）物理層。物理層主要由服務(wù)器、網(wǎng)絡(luò)連接設(shè)備、存儲設(shè)備等實際存在的基層設(shè)施組成，是容器管理系統(tǒng)的最底層的硬件條件;

（2）基礎(chǔ)設(shè)施層?；A(chǔ)設(shè)施層是塔建于實際設(shè)備之上的OpenStack管理系統(tǒng)，由計算資源池、存儲資源池以及網(wǎng)絡(luò)資源池共同組成。用于管理底層基礎(chǔ)設(shè)施，為容器管理系統(tǒng)虛擬機(jī)提供計算資源、存儲資源以及網(wǎng)絡(luò)資源;

（3）業(yè)務(wù)管理層。該層主要包括用戶管理、應(yīng)用管理、鏡像管理、基礎(chǔ)設(shè)施管理、告警管理、存儲管理、網(wǎng)絡(luò)管理、日志管理等容器管理系統(tǒng)的主要功能模塊;

（4）交互層。交互層主要負(fù)責(zé)業(yè)務(wù)管理層和用戶訪問層的數(shù)據(jù)交換過程。該層遵循RESTful風(fēng)格進(jìn)行兩層之間的通訊行為，以便用戶調(diào)用可視化頁面;

（5）用戶訪問層。該層是用戶直觀可見的一層，用戶通過UI頁面可以極簡單地作整個容器管理系統(tǒng)。

3.2? 功能模塊設(shè)計

本課題基于容器化改造后的運營商業(yè)務(wù)系統(tǒng)，設(shè)計出一個面向企業(yè)級的容器管理、容器化應(yīng)用管理系統(tǒng)ECP（Elastic Computing Platform，彈性計算平臺，簡稱ECP）。ECP為用戶提供輕量級的、穩(wěn)定的、可靠的容器，具有開箱即用的特性。其目標(biāo)是提供增強(qiáng)的容器、容器化應(yīng)用的全生命周期管理，同時基于其豐富的特性可以與企業(yè)已經(jīng)存在的業(yè)務(wù)系統(tǒng)和管理系統(tǒng)進(jìn)行集成。容器管理系統(tǒng)ECP的功能結(jié)構(gòu)圖如圖7所示。

ECP系統(tǒng)內(nèi)置豐富的容器鏡像及大量經(jīng)過驗證的微服務(wù)集群應(yīng)用，結(jié)合強(qiáng)大的應(yīng)用編排功能，可以使用戶在已有的IT基礎(chǔ)架構(gòu)之上快速構(gòu)建大規(guī)模具有彈性的應(yīng)用系統(tǒng)。容器管理系統(tǒng)提供的持續(xù)集成服務(wù)可以實現(xiàn)應(yīng)用編譯、構(gòu)建、測試、打包、發(fā)布的自動化流程，可保障業(yè)務(wù)的快速上線。ECP系統(tǒng)可提高業(yè)務(wù)效率，降低IT成本，擺脫繁雜的基礎(chǔ)架構(gòu)管理。ECP以Kubernetes為核心，整合了企業(yè)應(yīng)用所必須的監(jiān)控能力、數(shù)據(jù)存儲能力、網(wǎng)絡(luò)管理能力以及用戶管理、權(quán)限管理等，形成企業(yè)級可用的產(chǎn)品。ECP在Kubernetes的基礎(chǔ)上實現(xiàn)了應(yīng)用管理、用戶管理、采集、監(jiān)控、應(yīng)用QoS保證等容器管理系統(tǒng)必備的功能。

3.2.1? 應(yīng)用容器管理

應(yīng)用管理模塊主要提供集群管理、資源調(diào)度、應(yīng)用管理、應(yīng)用協(xié)調(diào)、容器擴(kuò)展和收縮、容器網(wǎng)絡(luò)/持久存儲、應(yīng)用負(fù)載均衡、灰色發(fā)布、應(yīng)用監(jiān)控和檢查等核心功能。利用Kubernetes增強(qiáng)了容器和應(yīng)用程序管理的核心功能，提供了應(yīng)用部署、維護(hù)、擴(kuò)展機(jī)制等功能。該系統(tǒng)的應(yīng)用可以方便地對運行的應(yīng)用進(jìn)行管理。其主要功能如下：首先，Docker用于打包、實例化和運行應(yīng)用程序;其次，以集群方式運行和管理跨機(jī)器容器;再次，解決Docker的跨機(jī)器容器之間的通訊問題;最后，容器集群的自愈機(jī)制使容器集群始終在用戶期望的狀態(tài)下運行。此外，Kubernetes是一個主從式集中系統(tǒng)，master主要組件如下所述，組件構(gòu)成如圖8所示。

（1）API Server：作為Kubernetes系統(tǒng)的入口，它封裝了核心對象的添加、刪除和重新檢查操作，并提供外部客戶和內(nèi)部組件調(diào)用的靜態(tài)風(fēng)格接口。它維護(hù)的REST對象將持久化到ETCD（一個分布式的、高度一致的密鑰/值存儲）;

（2）Scheduler：負(fù)責(zé)集群的資源調(diào)度，將機(jī)器分配給新的Pod;

（3）Controller-Manager：負(fù)責(zé)各種控制器的實現(xiàn)。目前有兩種類型，一是端點控制，主要負(fù)責(zé)服務(wù)和Pod的定期關(guān)聯(lián)（相關(guān)信息由端點對象維護(hù)），確保服務(wù)到pod的映射始終是最新的;二是復(fù)制控制器，主要負(fù)責(zé)定期關(guān)聯(lián)復(fù)制控制器和Pod，以確保復(fù)制控制器定義的拷貝數(shù)始終與實際運行Pod的拷貝數(shù)相同，并且通過設(shè)備運行兩個組件;

（4）kubelet：負(fù)責(zé)對容器進(jìn)行控制，如啟動/停止、監(jiān)控運行狀態(tài)等。它定期從ETCD獲取分配給本地機(jī)器的Pod，并根據(jù)Pod信息啟動或停止相應(yīng)的容器。同時，它還能收到API Server的HTTP請求，并報告Pod的運行狀態(tài)。

容器管理系統(tǒng)的應(yīng)用是由在邏輯上具備依賴關(guān)系的多組服務(wù)構(gòu)成的。應(yīng)用中的每個部分都由一個或多個容器組成，在應(yīng)用內(nèi)部形成一種能力（微服務(wù)）。多個微服務(wù)的組合形成一種對用戶有價值的服務(wù)能力。ECP系統(tǒng)以應(yīng)用整體的管理和服務(wù)保障為核心。例如，典型的LAMP應(yīng)用WordPress提供了基于PHP的博客功能，通常WordPress應(yīng)用由數(shù)據(jù)庫、PHP Web層、LB訪問控制層組成。在ECP系統(tǒng)中，這三層可分別使用應(yīng)用市場中的“MySQL數(shù)據(jù)庫”服務(wù)、多個同構(gòu)的PHP Web容器形成的服務(wù)以及一個負(fù)載均衡器。在ECP系統(tǒng)中，應(yīng)用將整個構(gòu)成WordPress的各部分看成一個整體，整體地對它們進(jìn)行操作和管理。應(yīng)用管理業(yè)務(wù)邏輯如圖9所示。

3.2.2? 用戶管理模塊

用戶管理模塊主要對容器管理系統(tǒng)中的用戶、租戶和角色三個概念實例進(jìn)行管理。用戶管理模塊整體架構(gòu)如圖10所示。

容器管理系統(tǒng)選擇復(fù)用的能力實現(xiàn)ECP系統(tǒng)的用戶、租戶和角色管理。其中，容器管理系統(tǒng)ECP中某些概念與OpenStack中相應(yīng)概念的映射如表1所示。

用戶管理模塊主要基于OpenStack體系中的KeyStone組件開發(fā)，并與其他子系統(tǒng)集成，包括底層IaaS平臺。KeyStone組件主要負(fù)責(zé)用戶權(quán)限認(rèn)證工作。該組件主要提供通用的用戶管理、多租戶管理及權(quán)限管理功能。除此之外，該組件還負(fù)責(zé)提供OpenStack體系中的其他組件的認(rèn)證工作。當(dāng)用戶希望使用系統(tǒng)中某個實例時，用戶會向租戶發(fā)送請求，該租戶會為用戶提供一個token。接下來，KeyStone會為用戶返回系統(tǒng)可提供的所有可供使用的服務(wù)列表，而用戶則根據(jù)自身需求向目標(biāo)服務(wù)發(fā)送token，待使用服務(wù)將驗證token。若驗證通過，KeyStone認(rèn)為用戶具備訪問和操作權(quán)限，服務(wù)才會執(zhí)行用戶發(fā)出的請求，最后用戶將收到服務(wù)執(zhí)行結(jié)果。反之，KeyStone將拒絕用戶發(fā)出的請求。

3.2.3? 日志管理模塊

在容器管理系統(tǒng)ECP系統(tǒng)環(huán)境中，容器和主機(jī)產(chǎn)生的日志分散在整個環(huán)境中，并沒有統(tǒng)一的方式進(jìn)行查看和管理，這種情況對企業(yè)監(jiān)控應(yīng)用的運行情況非常不利。因此，需要一個統(tǒng)一的日志管理系統(tǒng)來對日志的查詢、備份進(jìn)行控制。日志管理模塊主要提供面向主機(jī)、資源管理、應(yīng)用、容器及各種系統(tǒng)服務(wù)的日志統(tǒng)一收集、存儲和檢索功能。容器管理系統(tǒng)日志主要分為三種。日志管理架構(gòu)如圖11所示。

第一，系統(tǒng)日志，主要指容器管理系統(tǒng)各種服務(wù)、模塊組件的日志的收集、存儲和查詢功能;

第二，容器級日志，即通過Docker的日志管理功能來收集各個容器的日志，采用Logstash將日志收集到統(tǒng)一的ElasticSearch Cluster集中存儲并進(jìn)行分析;

第三，應(yīng)用日志，是基于ElasticSearch及應(yīng)用元信息實現(xiàn)面向應(yīng)用的日志管理和分析功能。

日志管理主要基于目前主流的EFK日志框架部署而成。EFK分別是Fluentd日志收集容器、Elasticsearch日志存儲容器和Kibana日志展示容器三大架構(gòu)的合稱。日志管理模塊采用SpringMVC技術(shù)來實現(xiàn)，其健康檢查等接口由StatissticContrller實現(xiàn)，日志的查詢、導(dǎo)出等功能由CanesController實現(xiàn)。CanesManager將傳遞來的請求轉(zhuǎn)換為合適的ElasticSearch查詢，并將結(jié)果進(jìn)行處理后返回。并在需要時將日志輸出到與FileServer共享的數(shù)據(jù)卷中，以便實現(xiàn)日志文件的導(dǎo)出。同時CanesManager還將自動定時清理ElasticSearch中的日志，自動將一個月前的所有日志清理掉。日志管理業(yè)務(wù)架構(gòu)如圖12所示。

4? 結(jié)? 論

本文根據(jù)容器管理系統(tǒng)ECP系統(tǒng)的不足之處進(jìn)行了進(jìn)一步分析，對容器管理系統(tǒng)的進(jìn)一步完善提出未來展望。

4.1? 本文總結(jié)

發(fā)展是互聯(lián)網(wǎng)時代中唯一不變的準(zhǔn)則。隨著時間的推移，大型項目會不斷增加，企業(yè)需求也將持續(xù)變更。與此同時，Docker技術(shù)的出現(xiàn)標(biāo)志著顛覆以往構(gòu)建和交付方式的技術(shù)已經(jīng)成熟。本文設(shè)計的容器管理系統(tǒng)證實了容器化技術(shù)給應(yīng)用管理、部署和管理帶來的變化。將OpenStack和Kubernetes集成起來構(gòu)建容器管理系統(tǒng)具有重要的現(xiàn)實意義和研究意義。

本課題基于運營商業(yè)務(wù)系統(tǒng)，首先分析了原有業(yè)務(wù)系統(tǒng)的體系結(jié)構(gòu)及功能等實際狀況，充分考慮到運營商的硬件支持情況，結(jié)合新型的輕量級虛擬化計算Docker，經(jīng)過幾番考量提出了一套容器化改造方案，并將該方案成功實施，為接下來的工作奠定基礎(chǔ);然后著手設(shè)計并實現(xiàn)了與容器化改造后已經(jīng)轉(zhuǎn)變?yōu)闊o狀態(tài)化運營商業(yè)務(wù)系統(tǒng)相配套的容器管理系統(tǒng)，提出了容器管理系統(tǒng)的整體架構(gòu);最后，本課題的研究表明了容器化技術(shù)和云計算技術(shù)與運營商業(yè)務(wù)系統(tǒng)相融是可行的，這為接下來的進(jìn)一步云化打下了堅實基礎(chǔ)。

4.2? 未來展望

目前，云計算已越來越被各行業(yè)所接受并應(yīng)用。因其為企業(yè)帶來的高效率轉(zhuǎn)化而成的高收益吸引許多傳統(tǒng)行業(yè)也開始向此方向轉(zhuǎn)變。然而，云計算和容器化技術(shù)的發(fā)展從未停歇。因此，本文還存在一些有待改進(jìn)和探索的方向。下一步的計劃研究工作如下所述。

（1）在容器管理系統(tǒng)設(shè)計和開發(fā)過程中，選擇將資源管理的功能、代碼邏輯等都放在同一個項目中。隨著業(yè)務(wù)需求的增加，系統(tǒng)往往會產(chǎn)生冗余，給容器管理系統(tǒng)的開發(fā)和維護(hù)帶來極大的不便。因此，提出進(jìn)一步優(yōu)化方案，即為了實現(xiàn)快速開發(fā)和部署，系統(tǒng)分為多種形式的微服務(wù)。分析各個功能和模塊，集成了一系列相關(guān)的功能和模塊構(gòu)建一個微服務(wù)項目來執(zhí)行某些特定的功能。本文提出的在容器管理系統(tǒng)中引入微服務(wù)，可以大大提高容器管理系統(tǒng)的可維護(hù)性和可擴(kuò)展性，有效地簡化業(yè)務(wù)邏輯之間的耦合。

（2）系統(tǒng)基于OpenStack云平臺提供云服務(wù)，用戶可以使用虛擬機(jī)、容器和其他資源，然而云服務(wù)可供使用的資源類型仍然有限。下一步，我們可以研究和實現(xiàn)更多類型的云服務(wù)，比如為用戶提供緩存、消息隊列、通用網(wǎng)站解決方案和其他服務(wù)，為用戶提供更多的云服務(wù)資源。

參考文獻(xiàn)：

[1] OpenStack Installation Guide for Ubuntu 12.04 （LTS）–HAVANA [EB/OL].（2016-11-24）.http：//docs.openstack.org/havana/install-guide/install/apt/content/.

[2] 2018 OpenStack User Survey Report [EB/OL].（2018-11-13）.https：//www.openstack.org/user-survey/2018-user-survey-report/.

[3] 張新朝.基于云平臺虛擬集群的設(shè)計與實現(xiàn) [D].漳州：閩南師范大學(xué)，2015.

[4] 王小軍，朱祎.虛擬化技術(shù)在云計算數(shù)據(jù)中心中的應(yīng)用研究 [J].電腦知識與技術(shù)，2014，10（4）：677-679.

[5] Opsahl J M G. Open-source virtualization：Functionality and performance of Qemu/KVM，Xen，Libvirt and VirtualBox [D/OL].Oslo：University of Oslo （2013-10-25）.https：//www.duo.uio.no/bitstream/Handle/10852/37427/1/Opsahl_Master.pdf.

[6] Muhammad Siraj Rathore，Markus Hidel，Peter Sj？din. KVM vs. LXC：Comparing Performance and Isolation of Hardware-assisted Virtual Routers [J].American Journal of Networks and Communications，2013，2（4）：88.

[7] Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures [D].American：University of California，2000.

[8] 管江華.大數(shù)據(jù)管理系統(tǒng)在云平臺上自動部署關(guān)鍵技術(shù)研究 [D].北京：中國科學(xué)院大學(xué)，2015.

[9] 馬建輝，賴濤.基于SOA架構(gòu)的異構(gòu)系統(tǒng)集成平臺的設(shè)計 [J].數(shù)字技術(shù)與應(yīng)用，2018，36（2）：158-159.

[10] OpenStack Services [EB/OL].（2018-7-15）.https：//www.openstack.org/software/project-navigator/openstack-components# openstack-services.

[11] 張炎華.私有云系統(tǒng)的實現(xiàn)及性能分析 [D].北京：北京郵電大學(xué)，2012.

[12] 周祥.私有云構(gòu)建中資源和數(shù)據(jù)管理的研究 [D].北京：北京工業(yè)大學(xué)，2012.

[13] 周洪波.云計算：技術(shù)、應(yīng)用、標(biāo)準(zhǔn)和商業(yè)模式 [M].北京：電子工業(yè)出版社，2011.

[14] John W. Rittinghouse，James F. Ransome.云計算實現(xiàn)、管理與安全 [M].田思源，趙學(xué)鋒，譯.北京：機(jī)械工業(yè)出版社，2010.

[15] 杜軍.基于Kubernetes的云端資源調(diào)度器改進(jìn) [D].杭州：浙江大學(xué)，2016.

[16] 楊海鋒.淺談云計算PaaS的發(fā)展及對IT產(chǎn)業(yè)的影響 [J].福建電腦，2012，28（11）：78-79.

[17] 程文迪，劉德民.Openstack云主機(jī)管理的敏捷開發(fā)技術(shù) [J].現(xiàn)代防御技術(shù)，2019，47（1）：169-175.

[18] 秦懷國.遼寧郵儲中間業(yè)務(wù)系統(tǒng)設(shè)計與開發(fā) [D].成都：電子科技大學(xué)，2014.

[19] Feng X，Shen J，F(xiàn)an Y. REST：An Alternative to RPC for Web Services Architecture [C].//International Conference on Future Information Networks. IEEE，2009：7-10.

[20] 朱智強(qiáng)，林韌昊，胡翠云，等.基于數(shù)字證書的openstack身份認(rèn)證協(xié)議 [J].通信學(xué)報，2019，40（2）：188-196.

[21] 邱晨，陳亞峰，周偉，等.基于容器化OpenStack云平臺及Ceph存儲的私有云實施案例 [J].郵電設(shè)計技術(shù)，2018（8）：51-56.

[22] 馮軒.基于Docker技術(shù)的Hadoop性能優(yōu)化研究 [D].南京：南京郵電大學(xué)，2018.

[23] 趙然，朱小勇.微服務(wù)架構(gòu)評述 [J].網(wǎng)絡(luò)新媒體技術(shù)，2019，8（1）：58-61+65.

作者簡介：王穎（1963.11-），男，漢族，河北唐山人，計算機(jī)科學(xué)與技術(shù)專業(yè)副教授，本科，研究方向：計算機(jī)網(wǎng)絡(luò)、云計算技術(shù)與應(yīng)用;鄒一榮（1982.09-），男，漢族，廣東惠州人，通信工程師，研究生，研究方向：云計算技術(shù)與應(yīng)用;吳家隱（1984.12-），男，漢族，廣東雷州人，畢業(yè)于中山大學(xué)，碩士，研究方向：云計算、半導(dǎo)體光電子。