朱明英,劉智瓊,池煒成
(中國電信股份有限公司廣東研究院,廣州510630)
隨著虛擬技術的發展,Docker 容器技術的出現給傳統的虛擬化帶來了很大的影響。不同于虛擬機的硬件虛擬化,容器采用的是基于操作系統層的虛擬化技術。由于Docker 容器使用公用的宿主OS 而不需要虛擬完整的GuestOS,使得容器的資源利用率遠高于虛擬機。除了資源利用性能上的優勢之外,容器最大的特點是可快速啟動。容器啟動速度在秒級,而虛擬機的啟動速度在分鐘級別。
容器技術和虛擬機技術的比較如表1 所示。
為順應用戶規模與使用量劇增的趨勢和業務轉型的要求,傳統的電信支撐系統的架構已經不能滿足要求。
當前電信支撐系統的架構面臨的挑戰主要有:
(1)敏捷思想帶來新的業務交付模式導致版本變更迭代加快
隨著互聯網業務不斷發展,要求業務需求以最快速度響應,迭代開發、向用戶交互高質量的軟件產品成為IT 軟件行業的必然選擇。
電信支撐系統需要采用分布式架構和容器化等技術,實現應用和服務的自動伸縮能力;基于微服務架構,構建統一、可重用的業務能力,實現對業務需求的快速響應。
(2)單體應用向微服務轉變,系統架構云化對運營理念帶來了新的要求
系統架構云化之后更加復雜,設備數量成倍數增長,給運維帶來很大的壓力和挑戰。在云化環境下IT資源高度虛擬化,加大整個架構的復雜度,各種業務應用、組件、虛擬機存在復雜的依賴關系,對系統監控全面性要求更高,當業務應用出現故障時,問題的定位變得更加復雜,這些方面成為云化架構下運營管理面臨的挑戰。
(3)互聯網帶來各種新技術和基礎框架導致組網復雜度劇變
在隨著云架構,云部署的實施,尤其是應用軟件SOA 化的轉型,應用集群化、冗余部署、應急、容災等應用組網越來越復雜。
而應用容器化后帶來的環境一致性和標準化、容器輕量化、基于容器的快速交付、彈性伸縮正好可以解決這類挑戰。
為應對上述挑戰,電信支撐系統需要采用“平臺+應用”的模式,基于容器化技術,按業務聚合特征構建云化的支撐系統,實現系統靈活可配置,應用水平彈性可擴展。
應用容器化后,有以下幾個方面的優勢:
(1)標準化
容器的運行時引擎是標準化的,目前使用的都是基于OCI(Open Container Initiative,開放容器組織)的技術規范實現的運行時引擎。
容器的鏡像也是標準化的,目前已有符合標準化的大量基礎鏡像,大大簡化了從零構建應用鏡像的難度。應用最終就是按鏡像標準制作成應用鏡像,運行在標準化的運行時引擎上。
開發流程是標準化的,采用容器技術可以給所有項目成員快速復制出一套完全一致的開發環境,從而消除因開發環境不同導致的不一致性,降低軟件缺陷出現的概率。
部署流程是標準化的。傳統的部署模式下,為了保證發布的軟件包在其他機器上可正常安裝且運行,一般需要在打包之前創建個干凈的環境,在這個干凈的環境下安裝各種依賴包,然后執行打包腳本。測試軟件包時,又需要再創建一個干凈的環境安裝、運行這個軟件包,非常繁瑣,并且容易漏掉依賴關系。容器化部署則從基礎鏡像開始(相當于干凈的環境),添加應用程序構建應用鏡像并部署,這個部署過程是自動化的,所以,通過容器化部署可以快速完成應用交付。
(2)版本控制
每一個容器的鏡像都有版本控制,這樣就可以追蹤不同版本的容器,監控版本之間的差異。
傳統模式下應用的升級,往往不僅僅是應用軟件本身的升級,通常還會包含依賴項的升級。但新舊軟件的依賴項可能是不同的,甚至是有沖突的,所以在傳統的環境下做回滾一般比較困難。
如果使用容器技術,容器鏡像的版本內集成了應用的軟件環境的全部信息,這些復雜的環境集成后,標記僅為一個版本,升級時先部署一個新的容器,看是否正常運行。需要回滾時,把新的容器停掉,啟動舊的容器即可完成回滾,整個過程在秒級完成,相對簡單,版本切換也變得快捷,版本升級和灰度發布,在容器鏡像簡單版本控制機制下,也變得較容易實現了。
(3)資源利用率高
容器與底層共享操作系統,性能優良,系統負載低,在同等條件下可以運行更多的應用實例,更充分地利用系統資源。同時,容器擁有資源隔離與限制能力,可以精確地對應用分配CPU、內存等資源,保證了應用間不會相互影響。
在傳統的基礎設施環境下,各業務需要的資源分配是分散管理的,各分散的業務部門通常按照規劃的最大額度申請物理機、虛擬機資源,這些資源即使空閑,也不能被別的業務部門使用,不能很好地解決資源共享和資源利用率的問題。
容器化方式下則是將業務應用集中管理,所有應用共享資源,各業務應用原來獨占的資源都共享出來形成資源池,利用Linux 內核的cgroup 機制,設置某個容器的資源配額,可以加大應用在宿主機上的部署密度,提升資源利用率。
(4)應用自動化運維
容器化應用具有的高可用能力降低了運維負擔,容器管理的集群架構,多節點資源冗余設計,保證應用在單節點出現故障時仍然可用。
應用容器化后,支持彈性伸縮,避免了傳統的擴容、部署、測試等繁瑣流程,減少了大量運維的工作量。
容器化后完善的日志和監控簡化了運維的工作,大量的自動告警技術和簡單易用的運維界面,實現了傳統模式難于實現的自動化運維。
(5)持續部署與測試
在傳統模式下,上線之前要把代碼提交到版本倉庫,進行構建,再發布到測試環境測試,之后發布到生產環境預測試,才能上線。這是典型的一個版本上線流程,其中的測試環境、預生產環境、生產環境之間有一定的差異,也存在一定的兼容性問題。
容器化后,依賴環境都集成到鏡像中,測試環境和生產環境保持一致,通過容器化后的持續部署與測試流程,能全流程管控產品,達到快速開發、集成和發布的目標,提高了產品的快速交付能力。
電信支撐系統通過云化改造后,絕大多數應用都適合部署成容器應用。這些應用可以分為有狀態應用和無狀態應用。應用的有狀態和無狀態是根據應用是否有持久化保存數據的需求而言的,即持久化保存數據的應用為有狀態的應用,反之則為無狀態的應用。
(1)有狀態應用
有狀態應用需要持久化保存數據;一般是數據類服務,如集群協調服務、日志分析等。Kubernetes 提供了持久化數據卷(Persistent Volume)的功能,可以實現數據的持久化保存,從而支持有狀態應用容器化。
容器化的有狀態應用由于其應用特性,所以不可隨意啟動、停止實例,不可隨意增加、刪除實例;服務實例發生故障后,需要立即進行維護以防止數據丟失和損壞。
雖然有狀態應用有這些限制,但仍然可以發揮容器化的下列優勢:
●容器方式部署和管理應用的能力
●利用容器一致性交付優勢
●實現快速部署和統一管理
(2)無狀態應用
無狀態應用對單次請求的處理不依賴其他請求,服務本身不存儲任何信息。無狀態容器化應用有以下特點:數據不落盤,或者只有臨時數據落盤;可以隨意啟動、停止和增加、刪除實例;應用實例發生故障后,可以立即刪除并通過模板創建新實例取而代之。
無狀態應用可以發揮容器的以下優勢:
●發揮容器方式部署和管理應用的能力
●利用容器一致性交付優勢
●實現快速部署和統一管理
●可運行在Kubernetes 提供的容器集群上
●由Kubernetes 提供高可靠、故障容忍、彈性伸縮、資源調度等功能
(3)不適合容器化改造的應用
如果應用有如下特點,不適合直接容器化,需要進行改造。
①使用大型中間件的應用
大型中間件主要是指如WebLogic、WebSphere、IBM MQ 等,這些中間件功能豐富,但是安裝配置復雜,資源占用率高,代碼不開源,進行容器化改造困難較大(因為閉源產品需要依賴閉源廠商對中間件進行容器化改造),這些都與容器輕量化的理念不符合。
②需要部署在一個操作系統中的多個強耦合應用
容器適用于運行單個應用,如果一個容器中運行多個應用,管理每個應用進程、存取日志、升級應用的時候就會很復雜。
③涉及內核操作的應用
容器本身是一個受到諸多管控的進程,隔離并不完全徹底,如果應用涉及到內核的操作,如自定義了驅動、內核模塊,可能導致宿主系統異常進而影響到其他容器應用異常。
④存儲了海量數據的數據庫
存儲了海量數據的數據庫對I/O 的要求高、網絡吞吐量高,這些要求容器還不能很好滿足。而容器的優勢如易于構建、彈性伸縮、維護環境一致性對于海量數據庫意義不大。
電信支撐系統容器化改造的關鍵點,主要包括如下方面:
(1)引入分布式框架
分布式服務治理框架可以加速系統微服務化的改造,并標準化開發過程,便于測試、部署。通過引入Dubbo 或Spring Cloud 等分布式服務治理框架,將應用微服務化,提升系統可擴展性和持續交付能力,實現系統的高可用。
(2)組件云化
推進“去IOE”,促進IT 系統x86 化,引入分布式數據庫、分布式緩存、分布式消息中間件等組件,極大提升系統彈性伸縮能力,降低系統負載壓力。
(3)應用與數據分離
通過將業務實現和業務數據進行分離,將業務數據實現無狀態化,前端業務通過統一的數據訪問引擎進行路由,可以極大的降低業務數據的安全風險;
(4)應用容器化改造
應用在容器化改造前,需要了解應用的運行環境、依賴包等,并且熟悉應用的部署形態。
①執行項目遷移:將應用工程遷移到容器化工程中進行管理。
②構建容器化環境:按運行環境和依賴包選擇基礎鏡像,按標準編寫Dockerfile。
③容器鏡像生成:在容器化工程中執行自動構建生產容器鏡像,完成容器化改造,統一交付鏡像。
④配置與應用分離:將應用的配置信息通過環境變量注入,或者通過從配置中心拉取配置的方式,來保障應用和配置分離。
本文通過對容器技術的研究,結合目前電信支撐系統的現狀,提出了利用容器技術解決電信支撐系統架構存在的問題,并對容器化改造后的優勢進行了分析。最后,給出了電信支撐系統容器化改造的適用范圍和改造關鍵點,為電信支撐系統架構的后續優化升級提供了借鑒意義。