計算資源利用率提高38%，廈航的容器化電商中臺構建實踐

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

來自Rancher、阿里雲、百度雲、平安科技、中國聯通、飛貸金融科技、中國人壽、SmartX、華泰保險、廈門航空、JFrog、新東方、Cisco等十多家企業的技術負責人，在大會上帶來了關於企業容器項目實踐經驗的精彩分享。

廈門航空和Rancher的合做能夠追溯到2年前。2017年，廈門航空完成了廈航雲計算平臺項目建設，基於Rancher、IaaS和CMP搭建了三位一體的廈門航空雲計算平臺。

「航空行業電商的發展催生了大量的業務請求訪問，平臺須要作到具有極強的穩定性和自動彈性收縮能力，而原有的傳統開發模式和軟件開發模式早已沒法知足現有的需求。」 廈門航空信息部系統工程師、雲平臺負責人周釗分享道：「在這樣的情形下，咱們找到了Rancher，經過自主研發及微服務架構與Rancher容器平臺完美結合，共同打造出廈航電商戰略的支持平臺。」

如下是廈門航空信息部系統工程師、雲平臺負責人周釗的演講實錄：

你們好，我是廈門航空信息部系統工程師周釗，今天和你們分享的主題是廈門航空基於微服務的電商中臺構建實踐。

廈門航空是一家主基地在廈門的國內中型航空公司。

在今天的演講中，我將和你們分享廈航的雲計算平臺。在2014年末，廈航雲計算平臺項目總體上線試運行，平臺包括三個部分。首先是你們熟悉的CMP混合雲管理平臺，而後是基於Open Stack架構的IaaS雲計算平臺，最後則是咱們今天的主角，Rancher容器雲平臺。

1. Rancher 1.6 + ELK

咱們最初上線的時候，Rancher的版本是1.6，咱們第一個容器化的應用是ELK，當時ELK運行在這個項目的另一部分、也就是OpenStack的IaaS平臺上，使用RBD存儲實現了整個ELK的數據持久化。咱們的ELK不只僅用在日誌分析等方面，咱們還把ES在一些查詢搜索等業務上作了普遍的推廣。

目前，咱們的ELK在Rancher的K8S平臺上進行遷移，也就是說咱們在Rancher和K8S上吃的第一個螃蟹仍是ELK。

上圖是當初ELK在1.6上的架構圖，和社區最佳實踐比較相似，在這裏就不詳細贅述了。

2. 容器化的電商中臺

這一部分是咱們的重點——廈門航空的容器化的電商中臺。

電商中臺和廈航的電商戰略是息息相關的。它做爲支撐平臺，能夠實現以機票銷售爲中心，把不一樣類型的乘客以不一樣形式的旅程，包括不一樣內容的附加服務，打包在一塊兒進行全流程服務，提高咱們整個航空公司的業務水平。

目前，廈航電商中臺對接了公司全部直銷渠道、線上OTA渠道，也就是說假如你如今拿起手機或者經過電腦，在官方渠道或其餘任何購票渠道上查詢廈航的機票、購買廈航的機票，都會通過咱們的電商中臺。

上圖是廈航電商中臺的架構圖。在這個圖裏面，除了紅色部分的Redis、消息隊列以及最下面的公共硬件LB設備，其餘組件都運行在Rancher 1.6平臺上。

上面這張是廈航電商中臺生產環境的截圖，包含咱們廈航電商中臺的全部服務。

這是在整個電商中臺第一次迎接比較大的考驗，對接阿里飛豬，當時我在Prometheus上截的圖，留做記念。裏面有一個處理到的數據，你們能夠看一下。

這張是前兩天準備PPT的時候截的圖，能夠側面看到咱們的業務增加量。

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

3. 電商中臺上線之路

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

咱們在整個開發測試環境裏實現了全流程的CI/CD流水線，整個電商中臺如今有單獨一套Harbor鏡像倉庫。

我在準備PPT的時候簡單統計了一下，近期每週鏡像的增加速度超過15G，這個數據是最低表現，有時每一週可能會有超過30G的鏡像增加量。單個服務在上線半年內有超過100屢次的功能更新，當中還不包括BUG的修復。

第二方面，我曾專門統計過容器在基礎資源的利用率。若是對比咱們整個電商中臺，若是用虛擬機作部署，Rancher節省的計算資源比例超過38%，這個和大會上午一位嘉賓分享的40%的數據是比較接近的。

第三方面，衆所周知，容器在靈活擴展和橫向擴展方面速度提高很是大。

最後一方面，廈航的團隊在基於Rancher API的基礎上開發了Publish-helper的工具，在Rancher 1.6平臺上實現接近無感知，也就是K8S這邊的灰度發佈的應用更新。這個工具支撐了廈航基本上全部生產環境的版本更新。

下面和你們分享咱們踩過的一些坑。剛纔咱們講到了容器化的一些好處，可是除此以外咱們也不是沒有踩過坑，主要是網絡、存儲和關鍵應用組件這三類。

首先是網絡，咱們一開始基礎平臺相對而言資源並非十分充裕。在最開始的時候，咱們用的是千兆網絡，在整個平臺裏面，咱們發現不少容器化的應用集羣並不能順利的初始化。

在排故過程當中，咱們存在大比例的網絡丟包。後來咱們分析，老舊的設備包括網卡等支持網絡多會話的特性較差。後來咱們就更新了總體設備，換到性能較好、特性較多的萬兆網絡。

可是咱們在系統上線前作了一次全鏈路的壓測，又發現單個容器尤爲是Rancher 1.6裏LB的容器，它的單容器網絡IO並不高。

上圖是咱們內網拿到的數據，萬兆網卡在VMWare環境下只有1.33G，在咱們的IaaS平臺上只有1G每秒的存儲。這個數據並不能達到咱們上線的需求。

通過和Rancher工程師幾回的調優，咱們把這個數據提高到大約4G每秒的存儲量，基本上和當時K8S Flannel的網絡是相似的。

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

第一個例子是上線前的一個檢查，咱們的Dockerfile是研發工程師寫的，在生產上線以前咱們會檢查，避免有一些不規範的地方。裏面有一個Docker volume。一開始檢查的時候，咱們只檢查Docker compose和Rancher compose文件，看裏面有沒有定義Docker volume。咱們後來發現有的研發人員在Dockerfile裏寫了Docker volume的指令，配合早期版本的Docker，它有一個特性，Volume的生命週期和Container是一致的。這就形成若是Container消失，Volume數據也會丟失。針對這些問題，咱們後來就增長了一些檢查。在咱們內部交接的時候，上線以前不只檢查Docker compose，還要檢查Dockerfile。

還有一個是我這邊的問題。在管理Rancher volume的時候，我把非active狀態的Rancher volume都刪掉了，應用就有人迅速反映說他的數據丟掉了。還好當時是測試環境。後來我在還原故障現場的時候，發現是Rancher裏面的一個特性，Container在重建的時候，Volume會有一個Detached的狀態。我刪掉的卷正好是Detached的狀態，其實active狀態的卷是沒法刪除的，Detached的狀態就能夠刪除了。咱們後面總結了一下，在管理Rancher Volume的時候，僅僅只關注紅色的inactive狀態的卷，其餘的卷通常不作清理，除非有特殊需求。

還有就是比較關鍵的、須要數據持久化的組件，包括一開始咱們電商中臺提到的Redis和消息隊列。這些組件咱們在測試環境也是全容器化的，可是在生產上線的時候，考慮它的數據穩定性，還有這些組件對咱們平臺的關鍵性做用，仍是把它放在虛機裏面。可是咱們還一直進行數據持久化關鍵組件的測試。

在Redis和Oracle以前，咱們還作過Cassandra還有PG的容器化測試，如今咱們在測試環境中也一直有這兩個組件運行。除此以外，咱們還作過一些比較極端的容器化測試，咱們將Oracle的12C作了單節點的容器化，也是跑的測試環境。

4. Rancher 2.x + 混合雲 + 多活數據中心

咱們計劃以Rancher爲中心，實現混合雲與多活數據中心的架構設計，這是咱們今年和Rancher合做的重點工做。

爲何廈航要作混合雲和多活數據中心呢？當廈航電商中臺上線以後，整個電商中臺的增加是很是迅速的。在咱們內部，我除了Rancher以外也負責技術平臺，包括服務器虛擬化等內容。而後我發現，只要我服務器到位，Rancher立刻就會產生需求，吃掉大部分資源。受限於咱們傳統的管理模式，咱們的數據中心基本上很難知足快速的擴容需求。

廈航電商中臺由於業務增加比較快，對接的系統也比較多，它的查詢和搜索壓力是十分龐大的。還有後期在咱們電商中臺的演進過程當中，它的架構也一直在變化。咱們須要更靈活的多種多樣的服務選型來知足咱們不一樣的業務場景需求，而這些問題偏偏是公有云最擅長的，因此咱們有了混合雲的需求。

關於多活數據中心，廈航在五年前就進行了兩地三中心的容災設計。在2017年5月，咱們實現了公司最核心的內部系統航班運行控制系統的一鍵切換。隨後，在2017年和2018年，咱們又把公司其餘的核心繫統，包括有三級評測的系統所有作了兩地三中心的容災建設。而如今，咱們要向多活數據中心演進。

咱們總結了兩個原則，一是標準化，一是服務化。咱們認爲，基於標準化和服務化雲應用，不只僅是應用了上層能夠對底層，並且是隨處能夠運行的，個人上層能夠利用任何一個底層，底層對於上層而言，又是透明的。

這個架構演進是比較清晰的，如今只有基礎設施層的標準化和服務化，也就是咱們說的IaaS，逐漸向上層演進，把咱們的數據層和咱們的中間件層也作成標準化和服務化的架構。最終走向全面的微服務架構演進。

這是我我的的一個觀點，K8S能夠承載一切。同時，咱們也開始關注K8S的生態，基於Rancher 1.6的經驗，咱們在K8S生態裏關注了Istio、Heptio、Calico等等組件。針對這些組件，咱們作了一些實踐和研究。

這是發在咱們內網的技術分享，包括Calico的路由反射器，大規模的K8S集羣維護，還有基於Heptio的備份和恢復。

我想重點說一下Calico，隨着IT企業對容器化和微服務化的改革以及演進，如今已經進入到深水區。像Calico這種重量級的網絡組件是很是有必要的。

隨着變革的深刻，大規模的K8S集羣愈來愈多，而Flannel是一個比較傻瓜化的網絡組件，不能知足企業對於容器網絡的需求。咱們很是須要一個企業級的容器網絡插件。

針對Rancher 2.2幾個統一的、標準化的特性，一個是K8S標準容器編排，以及Rancher 2.2對公有云的基礎設施服務，公有云託管K8S服務的統一管理，還有多集羣的應用管理。

咱們想經過Rancher 2.2的這些特性，在廈航的混合雲和多活數據中內心面造成一個橋樑和紐帶，串聯起咱們在每一個雲和每一個數據中內心面的業務。

在Rancher2.2上線以前，我還帶來了幾個問題。首先是K8S集羣的備份和持久卷的備份管理，還有K8S安全與安全域、多租戶隔離等等這些安全問題。以及剛纔提到的網絡控制、網絡隔離，最後一個是有狀態的應用集羣管理。

若是K8S能完美解決這些問題，那它離承載一切的目標或許就不遠了。

以上是我今天的演講，謝謝你們！