翁湦元,單杏花,閻志遠,王雪峰
(中國鐵道科學研究院集團有限公司 電子計算技術(shù)研究所,北京 100081)
隨著鐵路信息技術(shù)的不斷發(fā)展,旅客在對鐵路出行滿意度要求不斷提高的同時,對客運延伸服務(wù)也提出了更高的要求。隨著多樣化旅客出行服務(wù)需求的不斷提出,鐵旅App服務(wù)平臺也在不斷添加新的業(yè)務(wù)模塊,以便為旅客提供更好、更豐富的服務(wù)[1]。
不斷增多的應(yīng)用服務(wù)數(shù)量帶來了平臺的運維和升級問題。由于鐵旅App服務(wù)平臺采用微服務(wù)體系開發(fā),組件眾多且相互依賴,每次業(yè)務(wù)調(diào)整與升級均會涉及多個模塊的同時調(diào)整,導致業(yè)務(wù)升級緩慢,無法滿足快速迭代升級的要求,升級部署成功率低。平臺運維方面,以手工操作結(jié)合輔助腳本的方式為主,出錯率高,平臺穩(wěn)定性差。平臺各業(yè)務(wù)功能主要通過人工巡檢的方式進行日常維護,難以及時發(fā)現(xiàn)平臺故障,且故障修復(fù)周期長,增加了運維人員的工作量和人力成本。綜上,較長的升級研發(fā)周期,較高的平臺故障率以及較高的人工運維成本制約了平臺服務(wù)的深入開展,亟需探索提高平臺研發(fā)靈活性、穩(wěn)定性,降低運維成本的方法。
國內(nèi)外在云平臺建設(shè)方面取得了很多重要成果,現(xiàn)階段平臺建設(shè)領(lǐng)域的容器技術(shù)和容器編排工具是各大公司的研發(fā)主流。本文根據(jù)鐵旅App自身業(yè)務(wù)需求和特點,結(jié)合Kubernetes等開源工具搭建私有容器云平臺,將原業(yè)務(wù)系統(tǒng)進行容器化改造后遷移至云平臺,以達到提高平臺靈活性、穩(wěn)定性,降低運維成本的目的。
Docker是一個開源的應(yīng)用容器引擎,通過將應(yīng)用與相關(guān)的依賴項(環(huán)境、程序、文件)打包成鏡像文件,可以將其方便地部署于任何支持Docker運行環(huán)境的主機中,最大限度地消除開發(fā)環(huán)境與部署環(huán)境的差異,結(jié)合Docker鏡像倉庫,研發(fā)人員可以便捷地管理鏡像與交付版本[2]。同時,Docker與微服務(wù)架構(gòu)有著天然的契合度,因此可做為構(gòu)建容器云服務(wù)平臺的基礎(chǔ)。
對于大型企業(yè)而言,隨著系統(tǒng)平臺規(guī)模的不斷擴大,應(yīng)用服務(wù)數(shù)量和服務(wù)器數(shù)量也逐漸增加,運維成本不斷提高,單純依靠Docker已無法滿足系統(tǒng)運維需求。Kubernetes是Google的開源容器集群管理解決方案,在提供強大的集群管理、故障檢測與自動修復(fù)能力的同時,也提供便捷的服務(wù)升級解決方案,同時支持服務(wù)的發(fā)現(xiàn)調(diào)度和彈性伸縮等特性。鑒于Kubernetes有Google強大的開源支撐和眾多成功應(yīng)用的案例,基于Kubernetes構(gòu)建容器云服務(wù)平臺是大型企業(yè)構(gòu)建生產(chǎn)環(huán)境容器云服務(wù)平臺的較優(yōu)選擇之一[3]。
容器云平臺部署于物理服務(wù)器之上,總體結(jié)構(gòu)由資源層、平臺層、應(yīng)用層3部分組成,如圖1所示。
圖1 容器云平臺總體架構(gòu)圖
資源層位于平臺底層,為平臺提供基本存儲和資源管理能力,包含用于代碼版本管理的SVN,用于構(gòu)建Maven和Docker鏡像倉庫的Nexus,以及文件存儲服務(wù)。
平臺層包括容器云平臺的核心組件,如:集群監(jiān)控程序,用于提供容器鏡像基本運行能力的Docker工具,為Docker統(tǒng)一編排與調(diào)度能力的Kubernetes,用于將項目構(gòu)建為容器鏡像并上傳至Nexus倉庫中的Jenkins。
應(yīng)用層最接近用戶,用于部署為用戶開發(fā)的業(yè)務(wù)應(yīng)用,以及定制化的集群控制軟件等。
容器云平臺從項目全生命周期支持和自動化運維支持2個方面為開發(fā)人員提供服務(wù)。項目全生命周期支持包括代碼管理、持續(xù)構(gòu)建[4]、環(huán)境隔離、統(tǒng)一部署等多個功能,覆蓋項目啟動研發(fā)至部署上線全生命周期;自動化運維支持包括平臺監(jiān)控工具、故障自動恢復(fù)和水平擴容支持等功能,為運維人員提供了高效便捷的自動化工具。
2.2.1 項目全生命周期支持
容器云平臺圍繞項目全生命周期為研發(fā)人員提供如下服務(wù)。
(1)代碼管理
云平臺內(nèi)使用SVN作為代碼版本管理與協(xié)同開發(fā)的基礎(chǔ),項目研發(fā)人員統(tǒng)一將代碼提交至SVN進行代碼存儲。該功能是項目構(gòu)建的基礎(chǔ)。
(2)持續(xù)構(gòu)建
云平臺內(nèi)使用Jenkins作為持續(xù)構(gòu)建工具,通過定制的定時觸發(fā)和手動觸發(fā)機制,從SVN代碼倉庫中提取最新的項目源碼進行構(gòu)建、打包并推送至鏡像倉庫進行存儲,以便后續(xù)使用。
(3)環(huán)境隔離
云平臺利用Kubernetes命名空間資源隔離的特性為研發(fā)人員提供研發(fā)、預(yù)發(fā)布和生產(chǎn)環(huán)境,3個環(huán)境彼此隔離部署,使研發(fā)人員可以更安全地測試新業(yè)務(wù)而不影響線上正在運行的既有服務(wù)。
(4)統(tǒng)一部署工具
云平臺提供統(tǒng)一的項目發(fā)布工具,保持了平臺內(nèi)項目結(jié)構(gòu)的一致性,同時也將研發(fā)人員從Kubernetes工具繁瑣的操作流程中解放出來,降低了對研發(fā)人員的技術(shù)要求。統(tǒng)一的項目發(fā)布工具記錄了用戶的每一步操作,使得平臺應(yīng)用更新有跡可循,為潛在的業(yè)務(wù)升級故障風險提供了修復(fù)參考,統(tǒng)一部署界面如圖2所示。
2.2.2 自動化運維支持
(1)平臺監(jiān)控工具
云平臺監(jiān)控工具提供平臺運行狀態(tài)、物理節(jié)點、應(yīng)用狀態(tài)、服務(wù)調(diào)用負載等全方位監(jiān)控指標,為運維人員提供統(tǒng)一的監(jiān)控視圖,同時對平臺產(chǎn)生的異常提供釘釘自動報警功能,顯著縮短了故障的發(fā)現(xiàn)時間,降低了人工巡檢成本。平臺監(jiān)控的物理節(jié)點及應(yīng)用層監(jiān)控截圖如圖3所示。
圖2 統(tǒng)一部署管理界面截圖
圖3 物理節(jié)點及應(yīng)用層監(jiān)控截圖
(2)故障自動恢復(fù)
云平臺依賴鏡像倉庫保存了應(yīng)用的所有歷史版本,在出現(xiàn)應(yīng)用升級故障時,可以及時回滾為舊版應(yīng)用。
(3)水平擴容支持
通過容器封裝的應(yīng)用服務(wù)可以很方便地以增加副本的形式進行水平擴容,運維人員僅需根據(jù)負載需求設(shè)置副本數(shù)量即可。
在云平臺的日常運行中,不可避免會碰到節(jié)點失效的情況,比如,由于內(nèi)核安全漏洞、基礎(chǔ)軟件缺陷或硬件驅(qū)動Bug,甚至潛在的硬件故障和計劃性停機維護等導致需要在宿主機上進行重啟操作。容器云平臺需要采取必要的技術(shù)方案來降低節(jié)點重啟帶來的影響,保證容器云平臺的高可靠性。以下對部分關(guān)鍵技術(shù)方案進行說明。
2.3.1 可靠的文件、數(shù)據(jù)存儲系統(tǒng)
容器云平臺中對重要文件采用CEPH分布式文件系統(tǒng)進行存儲,以提供更高的可靠性和擴展性;對用戶數(shù)據(jù)采用主備方式建立數(shù)據(jù)庫集群;同時,采用ETCD集群為平臺提供高性能、高可靠性、高一致性的配置數(shù)據(jù)管理服務(wù)[5]。
2.3.2 Kubernetes集群高可用部署
容器云平臺中所有的用戶應(yīng)用均運行于Kubernetes環(huán)境之下,因此Kubernetes是容器云平臺的核心組件,對其可靠性有極高要求。鑒于Kubernetes中Master和ETCD存儲組件的重要性[6],在設(shè)計云平臺部署架構(gòu)時,通過Active-Active的Master多節(jié)點模式和ETCD服務(wù)集群方式來保障Kubernetes集群的穩(wěn)定性,使得僅當所有Master節(jié)點同時故障的情況下,才會影響平臺運行,任意單節(jié)點宕機均不會影響集群的正常運行。Kubernetes高可用集群結(jié)構(gòu)如圖4所示。
圖4 Kubernetes高可用集群結(jié)構(gòu)圖
2.3.3 應(yīng)用高可用部署
平臺用戶所部署的應(yīng)用均以容器的形式運行于Kubernetes環(huán)境下,Kubernetes通過Replication Controller/Replica Set[7]服務(wù)提供應(yīng)用副本的冗余性。用戶將需要部署的應(yīng)用打包為容器鏡像,以Deployment的形式部署于Kubernetes環(huán)境之下,通過合理設(shè)置Kubernetes應(yīng)用健康檢測探針和應(yīng)用部署的副本數(shù)量即可保證應(yīng)用的可靠運行。在出現(xiàn)節(jié)點故障或由于應(yīng)用本身的原因?qū)е鲁绦虮紳r,Kubernetes可自動重啟應(yīng)用或新建應(yīng)用副本,最終確??捎酶北緮?shù)量符合用戶設(shè)置。
2.3.4 多級監(jiān)控與自動報警
容器云平臺分別從系統(tǒng)、平臺、應(yīng)用3個層面對平臺健康狀況進行全方位監(jiān)控[8]。
(1)系統(tǒng)層面,在所有機器上部署Zabbix監(jiān)控客戶端,實時采集并上報宿主機和系統(tǒng)的關(guān)鍵指標,一旦發(fā)現(xiàn)故障則通過Zabbix觸發(fā)器將報警信息發(fā)送給運維人員,以便及時排除故障。
(2)平臺層面,通過自主研發(fā)的Kubernetes管理監(jiān)控服務(wù),調(diào)用Kubernetes的ApiServer定時查詢Kubernetes集群的關(guān)鍵指標,如節(jié)點運行狀態(tài)、網(wǎng)絡(luò)通信狀態(tài)、Kubernetes關(guān)鍵組件運行狀態(tài)等[9]。一旦發(fā)現(xiàn)Kubernetes集群內(nèi)部組件出現(xiàn)異常,立即通知平臺運維人員。
(3)應(yīng)用層面,該層面的監(jiān)控利用Kubernetes的健康狀態(tài)檢測探針機制,定期檢測應(yīng)用運行狀態(tài),當應(yīng)用運行狀態(tài)發(fā)生異常時,自動重啟故障副本并通知運維人員。
影響系統(tǒng)穩(wěn)定性的諸多原因中,人為因素也是很重要的一部分,因此需要盡可能避免人為因素造成的系統(tǒng)異常。結(jié)合容器云平臺特性,本文制定了一套開發(fā)、測試與部署的操作標準和流程[10]。
(1)研發(fā)人員應(yīng)以小步增量的方式進行研發(fā),保持較短的構(gòu)建和測試過程,維持較高的測試版本更新頻率;
(2)所有項目代碼、配置、說明文檔均上傳SVN進行版本管理,避免線下溝通和口頭溝通;
(3)設(shè)定版本里程碑,保證生產(chǎn)環(huán)境升級的有序性和計劃性,新增服務(wù)或升級服務(wù)在生產(chǎn)上線前必須通過開發(fā)環(huán)境測試和預(yù)發(fā)布環(huán)境灰度測試;
(4)通過權(quán)限設(shè)置禁止研發(fā)人員繞過統(tǒng)一部署平臺進行越權(quán)操作;
(5)研發(fā)人員必須依賴平臺內(nèi)代碼倉庫和組件私服以保證平臺范圍內(nèi)的關(guān)鍵代碼和組件的統(tǒng)一版本管理;
(6)編寫編碼規(guī)范手冊、集群操作手冊等相關(guān)文件,對平臺使用人員進行引導。
(1)利用Kubernetes的命名空間機制將平臺計算資源劃分為開發(fā)環(huán)境、預(yù)發(fā)布環(huán)境和生產(chǎn)環(huán)境3個相互獨立的子空間,實現(xiàn)不同環(huán)境的資源隔離,確保生產(chǎn)環(huán)境的安全與穩(wěn)定;
(2)研發(fā)人員將代碼托管至SVN服務(wù),在有效的版本控制機制下實現(xiàn)合作開發(fā);
(3)Jenkins組件負責定期提取SVN上的代碼,并按照項目配置構(gòu)建應(yīng)用鏡像,上傳至Nexus鏡像倉庫并打上相應(yīng)的版本標簽;
(4)在開發(fā)與測試階段,研發(fā)人員與測試人員均在開發(fā)環(huán)境下對正處于開發(fā)過程中的程序進行部署、升級、測試和調(diào)整,研發(fā)人員通過自主研發(fā)的Kubernetes管理服務(wù)統(tǒng)一進行應(yīng)用的部署與升級操作。
(5)新版發(fā)布階段,運維人員首先在預(yù)發(fā)布環(huán)境下部署最新版本的生產(chǎn)程序,并適當引入少量生產(chǎn)環(huán)境的流量進行灰度測試。
(6)當灰度測試通過后將新版本程序正式部署于生產(chǎn)環(huán)境,并最終完成程序的研發(fā)迭代過程。
系統(tǒng)研發(fā)的迭代流程如圖5所示。
圖5 研發(fā)流程示意圖
容器云平臺設(shè)計與搭建完畢后,將鐵旅App服務(wù)的業(yè)務(wù)系統(tǒng)進行遷移測試,得到如下實施效果。
(1)應(yīng)用部署效率提高
不同于原來手動拷貝副本并重啟應(yīng)用的升級方式,在容器云平臺內(nèi)部署應(yīng)用僅需在管理界面選擇自動構(gòu)建好的應(yīng)用鏡像并填入所需的副本數(shù)量即可,其余工作全部由Kubernetes自動完成。顯著降低部署難度,提升成功率,使原本3~5天1次的升級頻率提升為1天多次,且不影響服務(wù)的穩(wěn)定性。更高的部署效率令后臺可以更迅速地響應(yīng)產(chǎn)品需求,更快地推出更新、更完善的服務(wù)。
(2)服務(wù)故障率下降
借助容器云平臺的高可用架構(gòu)設(shè)計,可以實現(xiàn)有效冗余和故障自動恢復(fù),不再發(fā)生由于機器故障導致后臺無可用服務(wù)實例的情況,后臺服務(wù)整體穩(wěn)定性得到顯著提升。
(3)系統(tǒng)監(jiān)控能力提升
得益于容器云平臺的多級監(jiān)控機制,運維人員可以實現(xiàn)對系統(tǒng)、平臺、應(yīng)用的全方位監(jiān)控,監(jiān)控可以細化至每一個節(jié)點和應(yīng)用實例。監(jiān)控指標更加豐富,同時借助消息推送渠道,使軟硬件故障通知更為及時,響應(yīng)更加迅速。
(4)人員成本下降
容器云平臺將運維人員從大量繁瑣的手動操作步驟中解放出來,減少了大量原本需要手動記錄的部署信息,有效減少了運維人員的工作量。
容器云平臺基于Kubernetes技術(shù)將研發(fā)與運維人員從繁瑣的手工操作中解放出來,同時,為系統(tǒng)后臺提供了高可靠性、失敗冗余和容災(zāi)恢復(fù)等性能。容器云平臺在鐵旅App業(yè)務(wù)系統(tǒng)服務(wù)后臺的改造實踐中取得了良好效果。對于在大規(guī)模并發(fā)訪問和業(yè)務(wù)負載波動劇烈的情況下,如何應(yīng)用Kubernetes技術(shù)做到彈性自動擴容和動態(tài)分配系統(tǒng)資源仍待進一步研究。