計算資源利用率提升38%，廈航的容器化電商中臺構(gòu)建實踐

2019年6月20日，由Rancher Labs（以下簡稱Rancher）主辦的第三屆企業(yè)容器創(chuàng)新大會（Enterprise Container Innovation Conference, 以下簡稱ECIC）在北京喜來登大酒店盛大舉行。本屆ECIC規(guī)模宏大，全天共設(shè)置了17場主題演講，吸引了近1000名容器技術(shù)愛好者參加，超過10000名觀眾在線上直播平臺觀看了本次盛會。

來自Rancher、阿里云、百度云、平安科技、中國聯(lián)通、飛貸金融科技、中國人壽、SmartX、華泰保險、廈門航空、JFrog、新東方、Cisco等十多家企業(yè)的技術(shù)負(fù)責(zé)人，在大會上帶來了關(guān)于企業(yè)容器項目實踐經(jīng)驗的精彩分享。

cdn.xitu.io/2019/7/10/16bd9b3df6e5921c?w=1920&h=1280&f=jpeg&s=336198">

廈門航空和Rancher的合作可以追溯到2年前。2017年，廈門航空完成了廈航云計算平臺項目建設(shè)，基于Rancher、IaaS和CMP搭建了三位一體的廈門航空云計算平臺。

“航空行業(yè)電商的發(fā)展催生了大量的業(yè)務(wù)請求訪問，平臺需要做到具備極強(qiáng)的穩(wěn)定性和自動彈性收縮能力，而原有的傳統(tǒng)開發(fā)模式和軟件開發(fā)模式早已無法滿足現(xiàn)有的需求?！?廈門航空信息部系統(tǒng)工程師、云平臺負(fù)責(zé)人周釗分享道：“在這樣的情形下，我們找到了Rancher，通過自主研發(fā)及微服務(wù)架構(gòu)與Rancher容器平臺完美結(jié)合，共同打造出廈航電商戰(zhàn)略的支持平臺。”

以下是廈門航空信息部系統(tǒng)工程師、云平臺負(fù)責(zé)人周釗的演講實錄：

大家好，我是廈門航空信息部系統(tǒng)工程師周釗，今天和大家分享的主題是廈門航空基于微服務(wù)的電商中臺構(gòu)建實踐。

廈門航空是一家主基地在廈門的國內(nèi)中型航空公司。

在今天的演講中，我將和大家分享廈航的云計算平臺。在2014年底，廈航云計算平臺項目整體上線試運(yùn)行，平臺包括三個部分。首先是大家熟悉的CMP混合云管理平臺，然后是基于Open Stack架構(gòu)的IaaS云計算平臺，最后則是我們今天的主角，Rancher容器云平臺。

1. Rancher 1.6 + ELK

我們最初上線的時候，Rancher的版本是1.6，我們第一個容器化的應(yīng)用是ELK，當(dāng)時ELK運(yùn)行在這個項目的另外一部分、也就是OpenStack的IaaS平臺上，使用RBD存儲實現(xiàn)了整個ELK的數(shù)據(jù)持久化。我們的ELK不僅僅用在日志分析等方面，我們還把ES在一些查詢搜索等業(yè)務(wù)上做了廣泛的推廣。

目前，我們的ELK在Rancher的K8S平臺上進(jìn)行遷移，也就是說我們在Rancher和K8S上吃的第一個螃蟹還是ELK。

上圖是當(dāng)初ELK在1.6上的架構(gòu)圖，和社區(qū)最佳實踐比較類似，在這里就不詳細(xì)贅述了。

2. 容器化的電商中臺

這一部分是我們的重點(diǎn)——廈門航空的容器化的電商中臺。

電商中臺和廈航的電商戰(zhàn)略是息息相關(guān)的。它作為支撐平臺，可以實現(xiàn)以機(jī)票銷售為中心，把不同類型的乘客以不同形式的旅程，包括不同內(nèi)容的附加服務(wù)，打包在一起進(jìn)行全流程服務(wù)，提升我們整個航空公司的業(yè)務(wù)水平。

目前，廈航電商中臺對接了公司所有直銷渠道、線上OTA渠道，也就是說假如你現(xiàn)在拿起手機(jī)或者通過電腦，在官方渠道或其他任何購票渠道上查詢廈航的機(jī)票、購買廈航的機(jī)票，都會經(jīng)過我們的電商中臺。

上圖是廈航電商中臺的架構(gòu)圖。在這個圖里面，除了紅色部分的Redis、消息隊列以及最下面的公共硬件LB設(shè)備，其他組件都運(yùn)行在Rancher 1.6平臺上。

上面這張是廈航電商中臺生產(chǎn)環(huán)境的截圖，包含我們廈航電商中臺的所有服務(wù)。

這是在整個電商中臺第一次迎接比較大的考驗，對接阿里飛豬，當(dāng)時我在Prometheus上截的圖，留作紀(jì)念。里面有一個處理到的數(shù)據(jù)，大家可以看一下。

這張是前兩天準(zhǔn)備PPT的時候截的圖，可以側(cè)面看到我們的業(yè)務(wù)增長量。

講完廈航電商中臺的成果，我想藉這個機(jī)會再次感謝Rancher工程師對廈航電商中臺以及容器云平臺的大力支持。

3. 電商中臺上線之路

接下來，我們來回顧廈門電商中臺在容器化過程中，以及在測試上線過程中積累的一些經(jīng)驗和體會。Rancher帶給我們的提升首當(dāng)其沖的就是DevOps更新迭代的速度。

我們在整個開發(fā)測試環(huán)境里實現(xiàn)了全流程的CI/CD流水線，整個電商中臺現(xiàn)在有單獨(dú)一套Harbor鏡像倉庫。

我在準(zhǔn)備PPT的時候簡單統(tǒng)計了一下，近期每周鏡像的增長速度超過15G，這個數(shù)據(jù)是最低表現(xiàn)，有時每一周可能會有超過30G的鏡像增長量。單個服務(wù)在上線半年內(nèi)有超過100多次的功能更新，當(dāng)中還不包括BUG的修復(fù)。

第二方面，我曾專門統(tǒng)計過容器在基礎(chǔ)資源的利用率。如果對比我們整個電商中臺，如果用虛擬機(jī)做部署，Rancher節(jié)省的計算資源比例超過38%，這個和大會上午一位嘉賓分享的40%的數(shù)據(jù)是比較接近的。

第三方面，眾所周知，容器在靈活擴(kuò)展和橫向擴(kuò)展方面速度提升非常大。

最后一方面，廈航的團(tuán)隊在基于Rancher API的基礎(chǔ)上開發(fā)了Publish-helper的工具，在Rancher 1.6平臺上實現(xiàn)接近無感知，也就是K8S這邊的灰度發(fā)布的應(yīng)用更新。這個工具支撐了廈航基本上所有生產(chǎn)環(huán)境的版本更新。

下面和大家分享我們踩過的一些坑。剛才我們講到了容器化的一些好處，但是除此之外我們也不是沒有踩過坑，主要是網(wǎng)絡(luò)、存儲和關(guān)鍵應(yīng)用組件這三類。

首先是網(wǎng)絡(luò)，我們一開始基礎(chǔ)平臺相對而言資源并不是十分充裕。在最開始的時候，我們用的是千兆網(wǎng)絡(luò)，在整個平臺里面，我們發(fā)現(xiàn)很多容器化的應(yīng)用集群并不能順利的初始化。

在排故過程中，我們存在大比例的網(wǎng)絡(luò)丟包。后來我們分析，老舊的設(shè)備包括網(wǎng)卡等支持網(wǎng)絡(luò)多會話的特性較差。后來我們就更新了整體設(shè)備，換到性能較好、特性較多的萬兆網(wǎng)絡(luò)。

但是我們在系統(tǒng)上線前做了一次全鏈路的壓測，又發(fā)現(xiàn)單個容器尤其是Rancher 1.6里L(fēng)B的容器，它的單容器網(wǎng)絡(luò)IO并不高。

上圖是我們內(nèi)網(wǎng)拿到的數(shù)據(jù)，萬兆網(wǎng)卡在VMWare環(huán)境下只有1.33G，在我們的IaaS平臺上只有1G每秒的存儲。這個數(shù)據(jù)并不能達(dá)到我們上線的需求。

經(jīng)過和Rancher工程師幾次的調(diào)優(yōu)，我們把這個數(shù)據(jù)提升到大約4G每秒的存儲量，基本上和當(dāng)時K8S Flannel的網(wǎng)絡(luò)是類似的。

在存儲方面，我想先和大家分享幾個例子。

第一個例子是上線前的一個檢查，我們的Dockerfile是研發(fā)工程師寫的，在生產(chǎn)上線之前我們會檢查，避免有一些不規(guī)范的地方。里面有一個Docker volume。一開始檢查的時候，我們只檢查Docker compose和Rancher compose文件，看里面有沒有定義Docker volume。我們后來發(fā)現(xiàn)有的研發(fā)人員在Dockerfile里寫了Docker volume的指令，配合早期版本的Docker，它有一個特性，Volume的生命周期和Container是一致的。這就造成如果Container消失，Volume數(shù)據(jù)也會丟失。針對這些問題，我們后來就增加了一些檢查。在我們內(nèi)部交接的時候，上線之前不僅檢查Docker compose，還要檢查Dockerfile。

還有一個是我這邊的問題。在管理Rancher volume的時候，我把非active狀態(tài)的Rancher volume都刪掉了，應(yīng)用就有人迅速反映說他的數(shù)據(jù)丟掉了。還好當(dāng)時是測試環(huán)境。后來我在還原故障現(xiàn)場的時候，發(fā)現(xiàn)是Rancher里面的一個特性，Container在重建的時候，Volume會有一個Detached的狀態(tài)。我刪掉的卷正好是Detached的狀態(tài)，其實active狀態(tài)的卷是無法刪除的，Detached的狀態(tài)就可以刪除了。我們后面總結(jié)了一下，在管理Rancher Volume的時候，僅僅只關(guān)注紅色的inactive狀態(tài)的卷，其他的卷一般不做清理，除非有特殊需求。

還有就是比較關(guān)鍵的、需要數(shù)據(jù)持久化的組件，包括一開始我們電商中臺提到的Redis和消息隊列。這些組件我們在測試環(huán)境也是全容器化的，但是在生產(chǎn)上線的時候，考慮它的數(shù)據(jù)穩(wěn)定性，還有這些組件對我們平臺的關(guān)鍵性作用，還是把它放在虛機(jī)里面。但是我們還一直進(jìn)行數(shù)據(jù)持久化關(guān)鍵組件的測試。

在Redis和Oracle之前，我們還做過Cassandra還有PG的容器化測試，現(xiàn)在我們在測試環(huán)境中也一直有這兩個組件運(yùn)行。除此之外，我們還做過一些比較極端的容器化測試，我們將Oracle的12C做了單節(jié)點(diǎn)的容器化，也是跑的測試環(huán)境。

4. Rancher 2.x + 混合云 + 多活數(shù)據(jù)中心

我們計劃以Rancher為中心，實現(xiàn)混合云與多活數(shù)據(jù)中心的架構(gòu)設(shè)計，這是我們今年和Rancher合作的重點(diǎn)工作。

為什么廈航要做混合云和多活數(shù)據(jù)中心呢？當(dāng)廈航電商中臺上線之后，整個電商中臺的增長是非常迅速的。在我們內(nèi)部，我除了Rancher之外也負(fù)責(zé)技術(shù)平臺，包括服務(wù)器虛擬化等內(nèi)容。然后我發(fā)現(xiàn)，只要我服務(wù)器到位，Rancher馬上就會產(chǎn)生需求，吃掉大部分資源。受限于我們傳統(tǒng)的管理模式，我們的數(shù)據(jù)中心基本上很難滿足快速的擴(kuò)容需求。

廈航電商中臺因為業(yè)務(wù)增長比較快，對接的系統(tǒng)也比較多，它的查詢和搜索壓力是十分龐大的。還有后期在我們電商中臺的演進(jìn)過程中，它的架構(gòu)也一直在變化。我們需要更靈活的多種多樣的服務(wù)選型來滿足我們不同的業(yè)務(wù)場景需求，而這些問題恰恰是公有云最擅長的，所以我們有了混合云的需求。

關(guān)于多活數(shù)據(jù)中心，廈航在五年前就進(jìn)行了兩地三中心的容災(zāi)設(shè)計。在2017年5月，我們實現(xiàn)了公司最核心的內(nèi)部系統(tǒng)航班運(yùn)行控制系統(tǒng)的一鍵切換。隨后，在2017年和2018年，我們又把公司其他的核心系統(tǒng)，包括有三級評測的系統(tǒng)全部做了兩地三中心的容災(zāi)建設(shè)。而現(xiàn)在，我們要向多活數(shù)據(jù)中心演進(jìn)。

我們總結(jié)了兩個原則，一是標(biāo)準(zhǔn)化，一是服務(wù)化。我們認(rèn)為，基于標(biāo)準(zhǔn)化和服務(wù)化云應(yīng)用，不僅僅是應(yīng)用了上層可以對底層，而且是隨處可以運(yùn)行的，我的上層可以利用任何一個底層，底層對于上層而言，又是透明的。

這個架構(gòu)演進(jìn)是比較清晰的，現(xiàn)在只有基礎(chǔ)設(shè)施層的標(biāo)準(zhǔn)化和服務(wù)化，也就是我們說的IaaS，逐漸向上層演進(jìn)，把我們的數(shù)據(jù)層和我們的中間件層也做成標(biāo)準(zhǔn)化和服務(wù)化的架構(gòu)。最終走向全面的微服務(wù)架構(gòu)演進(jìn)。

這是我個人的一個觀點(diǎn)，K8S可以承載一切。同時，我們也開始關(guān)注K8S的生態(tài)，基于Rancher 1.6的經(jīng)驗，我們在K8S生態(tài)里關(guān)注了Istio、Heptio、Calico等等組件。針對這些組件，我們做了一些實踐和研究。

這是發(fā)在我們內(nèi)網(wǎng)的技術(shù)分享，包括Calico的路由反射器，大規(guī)模的K8S集群維護(hù)，還有基于Heptio的備份和恢復(fù)。

我想重點(diǎn)說一下Calico，隨著IT企業(yè)對容器化和微服務(wù)化的改革以及演進(jìn)，現(xiàn)在已經(jīng)進(jìn)入到深水區(qū)。像Calico這種重量級的網(wǎng)絡(luò)組件是非常有必要的。

隨著變革的深入，大規(guī)模的K8S集群越來越多，而Flannel是一個比較傻瓜化的網(wǎng)絡(luò)組件，不能滿足企業(yè)對于容器網(wǎng)絡(luò)的需求。我們非常需要一個企業(yè)級的容器網(wǎng)絡(luò)插件。

針對Rancher 2.2幾個統(tǒng)一的、標(biāo)準(zhǔn)化的特性，一個是K8S標(biāo)準(zhǔn)容器編排，以及Rancher 2.2對公有云的基礎(chǔ)設(shè)施服務(wù)，公有云托管K8S服務(wù)的統(tǒng)一管理，還有多集群的應(yīng)用管理。

我們想通過Rancher 2.2的這些特性，在廈航的混合云和多活數(shù)據(jù)中心里面形成一個橋梁和紐帶，串聯(lián)起我們在每個云和每個數(shù)據(jù)中心里面的業(yè)務(wù)。

在Rancher2.2上線之前，我還帶來了幾個問題。首先是K8S集群的備份和持久卷的備份管理，還有K8S安全與安全域、多租戶隔離等等這些安全問題。以及剛才提到的網(wǎng)絡(luò)控制、網(wǎng)絡(luò)隔離，最后一個是有狀態(tài)的應(yīng)用集群管理。

如果K8S能完美解決這些問題，那它離承載一切的目標(biāo)或許就不遠(yuǎn)了。

以上是我今天的演講，謝謝大家！