宗序梅 任彥輝

中國(guó)移動(dòng)通信集團(tuán)江蘇有限公司

1 引言

江蘇移動(dòng)公司業(yè)務(wù)云資源池主要為自有業(yè)務(wù)提供基于計(jì)算、存儲(chǔ)和網(wǎng)絡(luò)的IaaS層資源，承載了和娛樂(lè)、車(chē)衛(wèi)士、和教育、視頻能力等眾多的業(yè)務(wù)平臺(tái)，快速響應(yīng)了公司的業(yè)務(wù)發(fā)展。由于業(yè)務(wù)系統(tǒng)多采用的是傳統(tǒng)單體式應(yīng)用，組件眾多、布署耗時(shí)久、擴(kuò)容周期長(zhǎng)，無(wú)法靈活應(yīng)對(duì)突發(fā)的業(yè)務(wù)訪問(wèn)；同時(shí)基于虛擬化的云資源難以有效動(dòng)態(tài)調(diào)整，無(wú)法做到彈性擴(kuò)展，云資源池的利用率也無(wú)法有效提升。

和教育業(yè)務(wù)通過(guò)傳統(tǒng)的虛擬機(jī)承載相關(guān)的應(yīng)用模塊，云平臺(tái)提供基礎(chǔ)的IaaS層資源。隨著代碼量的增長(zhǎng)，每次更新代碼，必須進(jìn)行全面檢查以便確定對(duì)其他服務(wù)無(wú)影響，開(kāi)發(fā)效率較低；業(yè)務(wù)在高峰期需緊急申請(qǐng)主機(jī)布署業(yè)務(wù)，配置網(wǎng)絡(luò)策略，流程較長(zhǎng)。因此計(jì)劃通過(guò)對(duì)業(yè)務(wù)微服務(wù)化改造，降低應(yīng)用耦合性，減少開(kāi)發(fā)更新時(shí)間；同時(shí)結(jié)合容器平臺(tái)的功能，保障業(yè)務(wù)輕松擴(kuò)容。

2 PaaS技術(shù)說(shuō)明及架構(gòu)

2.1 技術(shù)說(shuō)明

基于容器的PaaS平臺(tái)為整個(gè)數(shù)據(jù)中心提供分布式調(diào)度與資源協(xié)調(diào)功能，實(shí)現(xiàn)數(shù)據(jù)中心級(jí)彈性伸縮能力的軟件堆棧，它將所有數(shù)據(jù)中心的資源當(dāng)做一臺(tái)計(jì)算機(jī)來(lái)調(diào)度和管理。

Kubernetes(k8s)是Google開(kāi)源的容器集群管理系統(tǒng),是一個(gè)基于容器技術(shù)構(gòu)建的數(shù)據(jù)中心操作系統(tǒng)的解決方案。在Docker技術(shù)的基礎(chǔ)上，為容器化的應(yīng)用提供部署運(yùn)行、資源調(diào)度、服務(wù)發(fā)現(xiàn)和動(dòng)態(tài)伸縮等一系列完整功能，提高了大規(guī)模容器集群管理的便捷性。

2.2 系統(tǒng)架構(gòu)

江蘇移動(dòng)公司在業(yè)務(wù)云資源池進(jìn)行PaaS的探索研究,基于Kubernetes開(kāi)源軟件在資源池改造6臺(tái)物理機(jī)，部署容器PaaS平臺(tái)。管理節(jié)點(diǎn)、負(fù)載均衡節(jié)點(diǎn)、鏡像倉(cāng)庫(kù)節(jié)點(diǎn)、日志告警節(jié)點(diǎn)和業(yè)務(wù)節(jié)點(diǎn)分散部署。

圖1 容器平臺(tái)架構(gòu)圖

master節(jié)點(diǎn)：主要由 apiserver、controller-manager、schduler等組成。

apiserver：作為kubernetes系統(tǒng)的入口，封裝了核心對(duì)象的增刪改查操作，以RESTFul接口方式提供給外部客戶(hù)和內(nèi)部組件使用。

controller-manager：負(fù)責(zé)執(zhí)行各種控制器。

schduler：負(fù)責(zé)集群的資源調(diào)度，為新建的pod（由一組緊耦合的容器組成的容器組）分配資源。

minion節(jié)點(diǎn)∶主要由kubelet、kube-proxy等組成。

kubelet：負(fù)責(zé)管控docker容器，如啟動(dòng)、停止、監(jiān)控運(yùn)行狀態(tài)等。它定期從etcd獲取分配到本機(jī)的pods，并根據(jù)pod信息啟動(dòng)或停止相應(yīng)的容器。同時(shí)，接收apiserver的http請(qǐng)求，匯報(bào)pods的運(yùn)行狀態(tài)。

proxy：負(fù)責(zé)為pod提供代理。定期從etcd中獲取所有的services，并根據(jù)service信息創(chuàng)建代理。當(dāng)某個(gè)客戶(hù)pod要訪問(wèn)其它pod時(shí)，訪問(wèn)請(qǐng)求會(huì)經(jīng)過(guò)本機(jī)proxy做轉(zhuǎn)發(fā)。

2.3 功能架構(gòu)

PaaS平臺(tái)由管理域和業(yè)務(wù)域兩部分組成。

管理域：管理模塊完全分布式微服務(wù)化，基于Kubernetes管理各個(gè)模塊，使得平臺(tái)模塊可以獨(dú)立升級(jí)和運(yùn)維，對(duì)模塊實(shí)現(xiàn)灰度發(fā)布、版本快速迭代。同時(shí)具有容錯(cuò)、自動(dòng)負(fù)載均衡和擴(kuò)縮容等功能。

業(yè)務(wù)域：業(yè)務(wù)運(yùn)行的節(jié)點(diǎn)，提供業(yè)務(wù)平臺(tái)運(yùn)行環(huán)境和訪問(wèn)途徑。業(yè)務(wù)域可以有多個(gè)集群，每個(gè)集群是完整的、獨(dú)立的一套Kubernetes集群。Kubernetes集群部署在物理機(jī)資源上，由PaaS統(tǒng)一管理，并提供裸計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)等資源。

圖2 容器平臺(tái)功能圖

平臺(tái)功能由七大功能模塊組成，分別是PaaS平臺(tái)應(yīng)用管理、日志管理、監(jiān)控告警、資源管理、鏡像倉(cāng)庫(kù)、服務(wù)管理域管理，主要面向平臺(tái)不同用戶(hù)角色提供相應(yīng)的功能。

應(yīng)用管理：運(yùn)行應(yīng)用的全生命周期管理，功能覆蓋應(yīng)用的代碼托管、應(yīng)用的發(fā)布管理、彈性伸縮、應(yīng)用配置等。

日志管理：實(shí)現(xiàn)系統(tǒng)組件和應(yīng)用日志的采集、分析、展示。

監(jiān)控告警：實(shí)現(xiàn)組件和應(yīng)用的監(jiān)控、告警功能。

資源管理：指運(yùn)行在PaaS平臺(tái)之上的所有服務(wù)組件及應(yīng)用的硬件資源環(huán)境的統(tǒng)一管理，涉及資源模板、資源分配與編排、資源注入等功能。

服務(wù)管理：指運(yùn)行在PaaS平臺(tái)上的所有服務(wù)組件的全生命周期管理，功能覆蓋服務(wù)上架、服務(wù)訂閱、服務(wù)目錄、服務(wù)運(yùn)行等。

鏡像倉(cāng)庫(kù)：可以讓開(kāi)發(fā)人員輕松存儲(chǔ)、管理和部署Docker 容器鏡像。采用分布式 的Docker鏡像服務(wù)架構(gòu)，支持快速、穩(wěn)定的Docker鏡像下載與發(fā)布。通過(guò)HTTPS傳輸容器鏡像，然后自動(dòng)對(duì)靜態(tài)映像進(jìn)行加密。

域管理：可以創(chuàng)建不同的用戶(hù)、角色和域。各用戶(hù)創(chuàng)建的資源池相對(duì)獨(dú)立，互不影響。

3 和教育業(yè)務(wù)微服務(wù)改造

3.1 微服務(wù)組件框架

和教育微服務(wù)組件基于Spring Cloud框架開(kāi)發(fā)，Spring Cloud框架的基本組件與關(guān)系如下：

圖3 微服務(wù)組件框架圖

網(wǎng)關(guān)：通過(guò)服務(wù)網(wǎng)關(guān)統(tǒng)一向外系統(tǒng)提供RESTFul API，除了具備服務(wù)路由、均衡負(fù)載功能之外，它還具備了權(quán)限控制等功能。將權(quán)限控制這些較重的非業(yè)務(wù)邏輯內(nèi)容遷移到服務(wù)路由層面，使得服務(wù)集群主體能夠具備更高的可復(fù)用性和可測(cè)試性。

注冊(cè)中心：用于云端服務(wù)發(fā)現(xiàn)與定位服務(wù)，以實(shí)現(xiàn)云端中間層服務(wù)發(fā)現(xiàn)和故障轉(zhuǎn)移。客戶(hù)端向注冊(cè)中心提供關(guān)于自己的元數(shù)據(jù)（諸如主機(jī)和端口，健康指標(biāo)URL，首頁(yè)等）。

配置中心：把應(yīng)用原本放在本地文件的配置抽取出來(lái)放在中心服務(wù)器，從而能夠提供更好的管理、發(fā)布能力。SpringCloudCon fi g分服務(wù)端和客戶(hù)端，服務(wù)端負(fù)責(zé)將Git中存儲(chǔ)的配置文件發(fā)布成RESTFul接口，客戶(hù)端可以從服務(wù)端RESTFul接口獲取配置。

微服務(wù)：微服務(wù)應(yīng)用，即開(kāi)發(fā)的具體應(yīng)用，向注冊(cè)中心注冊(cè)，從配置中心獲取具體配置，由網(wǎng)關(guān)調(diào)用以實(shí)現(xiàn)訪問(wèn)。

3.2 微服務(wù)網(wǎng)絡(luò)

PaaS平臺(tái)中針對(duì)每個(gè)微服務(wù)應(yīng)用啟動(dòng)多個(gè)pod，微服務(wù)應(yīng)用本身遵循Spring Cloud的架構(gòu)模式，向注冊(cè)中心注冊(cè)，從配置中心取配置。pod之間的訪問(wèn)地址為Kubernetes架構(gòu)下的虛擬IP，以避免容器重啟后容器IP變化導(dǎo)致的無(wú)法訪問(wèn)問(wèn)題。

在對(duì)外提供服務(wù)時(shí)，使用PaaS提供的負(fù)載均衡器，只需將網(wǎng)關(guān)服務(wù)對(duì)外暴露，即可保證整個(gè)微服務(wù)系統(tǒng)的可訪問(wèn)性。在這種部署方式中，每一個(gè)微服務(wù)都能夠無(wú)中斷的自由擴(kuò)展或縮減容器數(shù)量，以應(yīng)對(duì)服務(wù)高峰期或低谷期的不同訪問(wèn)壓力，且無(wú)需更改其他配置。

和教育微服務(wù)中的應(yīng)用除discovery和con fi g以外，均對(duì)外提供服務(wù)，所有的請(qǐng)求均是通過(guò)網(wǎng)關(guān)服務(wù)來(lái)傳達(dá)的，因此微服務(wù)架構(gòu)中只需暴露網(wǎng)關(guān)服務(wù)即可。在Kubernetes環(huán)境中，客戶(hù)端發(fā)來(lái)的請(qǐng)求首先經(jīng)過(guò)硬件負(fù)載均衡分發(fā)到Nginx代理，然后通過(guò)Nginx ingress分發(fā)到不同的微服務(wù)應(yīng)用上。

圖4 微服務(wù)網(wǎng)絡(luò)架構(gòu)圖

4 微服務(wù)改造效果

和教育平臺(tái)經(jīng)過(guò)微服務(wù)化改造后：

（1）應(yīng)用彈性伸縮、水平擴(kuò)展，擴(kuò)容周期提高到秒級(jí)：結(jié)合PaaS平臺(tái)的水平擴(kuò)展功能、微服務(wù)的自動(dòng)發(fā)現(xiàn)與注冊(cè)，保障了和教育在開(kāi)學(xué)季訪問(wèn)高峰期只需要增加容器數(shù)量就可以滿(mǎn)足擴(kuò)容；通過(guò)設(shè)置CPU和內(nèi)存利用率閾值，實(shí)現(xiàn)容器自動(dòng)擴(kuò)容。

（2）軟件系統(tǒng)開(kāi)發(fā)解耦，縮短代碼更新時(shí)間，上線周期縮短60%：和教育業(yè)務(wù)，對(duì)資源配置需求靈活，客戶(hù)端接口模塊進(jìn)行微服務(wù)化后，降低耦合性，減少了開(kāi)發(fā)更新的時(shí)間；編寫(xiě)代碼提交到自動(dòng)編譯打包、持續(xù)集成、自動(dòng)部署上線全流程自動(dòng)化。

（3）應(yīng)用服務(wù)實(shí)時(shí)檢測(cè)、故障自動(dòng)恢復(fù)，提升業(yè)務(wù)可靠性：PaaS系統(tǒng)平臺(tái)設(shè)置監(jiān)控粒度及監(jiān)控對(duì)象，自動(dòng)重啟故障應(yīng)用；微服務(wù)的健康檢查能夠自動(dòng)踢除無(wú)效應(yīng)用，對(duì)微服務(wù)組件的可靠性起到了極大的提升作用。

（4）資源精細(xì)化運(yùn)營(yíng)，內(nèi)存利用率由原來(lái)40%提升到80%：和教育客戶(hù)端組件原來(lái)承載于10臺(tái)虛擬機(jī)，內(nèi)存峰值利用率40%左右。微服務(wù)化后布署了45個(gè)Pod，內(nèi)存峰值利用率達(dá)到80%。

5 結(jié)束語(yǔ)

PaaS平臺(tái)基于Kubernetes技術(shù)，具有高擴(kuò)展性、高兼容性、負(fù)載均衡、灰度升級(jí)、失敗冗余、容災(zāi)恢復(fù)等優(yōu)點(diǎn)。在使用中適合對(duì)這些因素有要求的場(chǎng)景，如：高峰時(shí)段和低谷時(shí)段業(yè)務(wù)量差異巨大，業(yè)務(wù)負(fù)載波動(dòng)劇烈，且波峰不可預(yù)估；高峰期業(yè)務(wù)資源需求高，很多應(yīng)用面臨快速上線的壓力；服務(wù)組件眾多，每次部署需要耗費(fèi)很長(zhǎng)時(shí)間，且容錯(cuò)能力比較薄弱，無(wú)法應(yīng)對(duì)大規(guī)模并發(fā)訪問(wèn)等。結(jié)合容器化本身的特性，此系統(tǒng)更適合于模塊化程度高的應(yīng)用系統(tǒng)。