溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
2019年6月20日，由Rancher Labs（以下簡稱Rancher）主辦的第三屆企業容器創新大會（Enterprise Container Innovation Conference, 以下簡稱ECIC）在北京喜來登大酒店盛大舉行。本屆ECIC規模宏大，全天共設置了17場主題演講，吸引了近1000名容器技術愛好者參加，超過10000名觀眾在線上直播平臺觀看了本次盛會。
來自Rancher、阿里云、百度云、平安科技、中國聯通、飛貸金融科技、中國人壽、SmartX、華泰保險、廈門航空、JFrog、新東方、Cisco等十多家企業的技術負責人，在大會上帶來了關于企業容器項目實踐經驗的精彩分享。
cdn.xitu.io/2019/7/10/16bd9b3df6e5921c?w=1920&h=1280&f=jpeg&s=336198">
廈門航空和Rancher的合作可以追溯到2年前。2017年，廈門航空完成了廈航云計算平臺項目建設，基于Rancher、IaaS和CMP搭建了三位一體的廈門航空云計算平臺。
“航空行業電商的發展催生了大量的業務請求訪問，平臺需要做到具備極強的穩定性和自動彈性收縮能力，而原有的傳統開發模式和軟件開發模式早已無法滿足現有的需求。” 廈門航空信息部系統工程師、云平臺負責人周釗分享道：“在這樣的情形下，我們找到了Rancher，通過自主研發及微服務架構與Rancher容器平臺完美結合，共同打造出廈航電商戰略的支持平臺。”
以下是廈門航空信息部系統工程師、云平臺負責人周釗的演講實錄：
大家好，我是廈門航空信息部系統工程師周釗，今天和大家分享的主題是廈門航空基于微服務的電商中臺構建實踐。
廈門航空是一家主基地在廈門的國內中型航空公司。
在今天的演講中，我將和大家分享廈航的云計算平臺。在2014年底，廈航云計算平臺項目整體上線試運行，平臺包括三個部分。首先是大家熟悉的CMP混合云管理平臺，然后是基于Open Stack架構的IaaS云計算平臺，最后則是我們今天的主角，Rancher容器云平臺。
我們最初上線的時候，Rancher的版本是1.6，我們第一個容器化的應用是ELK，當時ELK運行在這個項目的另外一部分、也就是OpenStack的IaaS平臺上，使用RBD存儲實現了整個ELK的數據持久化。我們的ELK不僅僅用在日志分析等方面，我們還把ES在一些查詢搜索等業務上做了廣泛的推廣。
目前，我們的ELK在Rancher的K8S平臺上進行遷移，也就是說我們在Rancher和K8S上吃的第一個螃蟹還是ELK。
上圖是當初ELK在1.6上的架構圖，和社區最佳實踐比較類似，在這里就不詳細贅述了。
這一部分是我們的重點——廈門航空的容器化的電商中臺。
電商中臺和廈航的電商戰略是息息相關的。它作為支撐平臺，可以實現以機票銷售為中心，把不同類型的乘客以不同形式的旅程，包括不同內容的附加服務，打包在一起進行全流程服務，提升我們整個航空公司的業務水平。
目前，廈航電商中臺對接了公司所有直銷渠道、線上OTA渠道，也就是說假如你現在拿起手機或者通過電腦，在官方渠道或其他任何購票渠道上查詢廈航的機票、購買廈航的機票，都會經過我們的電商中臺。
上圖是廈航電商中臺的架構圖。在這個圖里面，除了紅色部分的Redis、消息隊列以及最下面的公共硬件LB設備，其他組件都運行在Rancher 1.6平臺上。
上面這張是廈航電商中臺生產環境的截圖，包含我們廈航電商中臺的所有服務。
這是在整個電商中臺第一次迎接比較大的考驗，對接阿里飛豬，當時我在Prometheus上截的圖，留作紀念。里面有一個處理到的數據，大家可以看一下。
這張是前兩天準備PPT的時候截的圖，可以側面看到我們的業務增長量。
講完廈航電商中臺的成果，我想藉這個機會再次感謝Rancher工程師對廈航電商中臺以及容器云平臺的大力支持。
接下來，我們來回顧廈門電商中臺在容器化過程中，以及在測試上線過程中積累的一些經驗和體會。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做了單節點的容器化，也是跑的測試環境。
我們計劃以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能完美解決這些問題，那它離承載一切的目標或許就不遠了。
以上是我今天的演講，謝謝大家！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
