王穎 鄒一榮 吳家隱

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

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

中圖分類號(hào)：TP393.09? ? ? 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：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)容包括以下三個(gè)方面：第一，從實(shí)際情況出發(fā)，提出從三個(gè)方面對(duì)原運(yùn)營商業(yè)務(wù)系統(tǒng)進(jìn)行應(yīng)用改造，以及測試改造后的應(yīng)用是否適應(yīng)容器化部署;第二，分析多種容器化技術(shù)的優(yōu)缺點(diǎn)，結(jié)合實(shí)際的運(yùn)營商業(yè)務(wù)系統(tǒng)，從不同方案中選擇合理且高效的容器化部署方案;第三，根據(jù)容器化部署方案，設(shè)計(jì)相應(yīng)的容器管理系統(tǒng)ECP系統(tǒng)。

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

1? 緒論

1.1? 課題背景及研究意義

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如果應(yīng)用程序在PaaS平臺(tái)上動(dòng)態(tài)擴(kuò)展，則需要對(duì)應(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)行請(qǐng)求分發(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會(huì)話作為會(huì)話保持的方案;其次，采用http與JSON相結(jié)合的方式作為客戶端與Web端的交互手段;最后，使用緩存服務(wù)器為用戶存儲(chǔ)會(huì)話信息。改造后的結(jié)構(gòu)如圖2所示。

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

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

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

2.2? 配置中心化改造

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

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

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

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

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

2.3? 日志中心化改造

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本課題基于容器化改造后的運(yùn)營商業(yè)務(wù)系統(tǒng)，設(shè)計(jì)出一個(gè)面向企業(yè)級(jí)的容器管理、容器化應(yīng)用管理系統(tǒng)ECP（Elastic Computing Platform，彈性計(jì)算平臺(tái)，簡稱ECP）。ECP為用戶提供輕量級(jí)的、穩(wěn)定的、可靠的容器，具有開箱即用的特性。其目標(biāo)是提供增強(qiáng)的容器、容器化應(yīng)用的全生命周期管理，同時(shí)基于其豐富的特性可以與企業(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)過驗(yàn)證的微服務(wù)集群應(yīng)用，結(jié)合強(qiáng)大的應(yīng)用編排功能，可以使用戶在已有的IT基礎(chǔ)架構(gòu)之上快速構(gòu)建大規(guī)模具有彈性的應(yīng)用系統(tǒng)。容器管理系統(tǒng)提供的持續(xù)集成服務(wù)可以實(shí)現(xiàn)應(yīng)用編譯、構(gòu)建、測試、打包、發(fā)布的自動(dòng)化流程，可保障業(yè)務(wù)的快速上線。ECP系統(tǒng)可提高業(yè)務(wù)效率，降低IT成本，擺脫繁雜的基礎(chǔ)架構(gòu)管理。ECP以Kubernetes為核心，整合了企業(yè)應(yīng)用所必須的監(jiān)控能力、數(shù)據(jù)存儲(chǔ)能力、網(wǎng)絡(luò)管理能力以及用戶管理、權(quán)限管理等，形成企業(yè)級(jí)可用的產(chǎn)品。ECP在Kubernetes的基礎(chǔ)上實(shí)現(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ò)/持久存儲(chǔ)、應(yīng)用負(fù)載均衡、灰色發(fā)布、應(yīng)用監(jiān)控和檢查等核心功能。利用Kubernetes增強(qiáng)了容器和應(yīng)用程序管理的核心功能，提供了應(yīng)用部署、維護(hù)、擴(kuò)展機(jī)制等功能。該系統(tǒng)的應(yīng)用可以方便地對(duì)運(yùn)行的應(yīng)用進(jìn)行管理。其主要功能如下：首先，Docker用于打包、實(shí)例化和運(yùn)行應(yīng)用程序;其次，以集群方式運(yùn)行和管理跨機(jī)器容器;再次，解決Docker的跨機(jī)器容器之間的通訊問題;最后，容器集群的自愈機(jī)制使容器集群始終在用戶期望的狀態(tài)下運(yùn)行。此外，Kubernetes是一個(gè)主從式集中系統(tǒng)，master主要組件如下所述，組件構(gòu)成如圖8所示。

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

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

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

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

容器管理系統(tǒng)的應(yīng)用是由在邏輯上具備依賴關(guān)系的多組服務(wù)構(gòu)成的。應(yīng)用中的每個(gè)部分都由一個(gè)或多個(gè)容器組成，在應(yīng)用內(nèi)部形成一種能力（微服務(wù)）。多個(gè)微服務(wù)的組合形成一種對(duì)用戶有價(jià)值的服務(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è)同構(gòu)的PHP Web容器形成的服務(wù)以及一個(gè)負(fù)載均衡器。在ECP系統(tǒng)中，應(yīng)用將整個(gè)構(gòu)成WordPress的各部分看成一個(gè)整體，整體地對(duì)它們進(jìn)行操作和管理。應(yīng)用管理業(yè)務(wù)邏輯如圖9所示。

3.2.2? 用戶管理模塊

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

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

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

3.2.3? 日志管理模塊

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

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

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

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

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

4? 結(jié)? 論

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

4.1? 本文總結(jié)

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

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

4.2? 未來展望

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

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

（2）系統(tǒng)基于OpenStack云平臺(tái)提供云服務(wù)，用戶可以使用虛擬機(jī)、容器和其他資源，然而云服務(wù)可供使用的資源類型仍然有限。下一步，我們可以研究和實(shí)現(xiàn)更多類型的云服務(wù)，比如為用戶提供緩存、消息隊(duì)列、通用網(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] 張新朝.基于云平臺(tái)虛擬集群的設(shè)計(jì)與實(shí)現(xiàn) [D].漳州：閩南師范大學(xué)，2015.

[4] 王小軍，朱祎.虛擬化技術(shù)在云計(jì)算數(shù)據(jù)中心中的應(yīng)用研究 [J].電腦知識(shí)與技術(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)在云平臺(tái)上自動(dòng)部署關(guān)鍵技術(shù)研究 [D].北京：中國科學(xué)院大學(xué)，2015.

[9] 馬建輝，賴濤.基于SOA架構(gòu)的異構(gòu)系統(tǒng)集成平臺(tái)的設(shè)計(jì) [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)的實(shí)現(xiàn)及性能分析 [D].北京：北京郵電大學(xué)，2012.

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

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

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

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

[16] 楊海鋒.淺談云計(jì)算PaaS的發(fā)展及對(duì)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] 秦懷國.遼寧郵儲(chǔ)中間業(yè)務(wù)系統(tǒng)設(shè)計(jì)與開發(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é)報(bào)，2019，40（2）：188-196.

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

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

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

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