微服務架構下的一體化運維監控系統的設計與實踐

【摘要】" " 本文借鑒業界互聯網公司在微服務、容器化監控方面的先進技術和經驗，以服務視角設計了新一代云原生一體化運維監控系統，并介紹了該系統在實際應用中的價值成效，為傳統運營商運維支撐管理體系轉型發展及創新實踐提供了借鑒。

【關鍵詞】" " 云原生" " 一體化" " 運維監控" " 運營商

一、云原生架構面臨的挑戰

隨著運營商第三代業務支撐系統逐步向微服務化（云原生）架構演進，運營商業務生產環境日益復雜、技術棧多、技術組件復雜、服務數量激增以及服務間的靈活調用，使得微服務架構下的監控運維工作面臨“傳統手段不再適配”、“故障定界更加復雜”、“監控數據規模體量劇增”等挑戰。

1.1傳統監控手段不再適配

容器化改造后，容器實例對象等基礎資源動態可變，一般多副本pod實例發生故障時候會在其他節點上強制拉起。同時，容器化應用的變更、滾動升級，可能新增數百、數千個容器，并同時拉起，傳統人工方式配置及被動發現監控點無法應對云資源動態變化的監控場景。

1.2故障定界更加復雜

微服務改造后，服務數量激增且服務間調用關系錯蹤復雜，在整個服務鏈條中，如果有任何一個服務節點出現了延遲或問題會使得影響整體服務，傳統黑盒監控手段無法排查鏈條中具體哪個服務節點出現問題。

1.3監控數據規模體量劇增

業務快速發展，各上層業務應用持續快速構建，使得監控數據爆炸式增長，傳統關系型數據庫難以支撐海量監控數據的實時讀寫，運維人員無法快速處理系統異常。

針對以上痛點問題，本文借鑒業界互聯網公司在微服務、容器化監控方面的先進技術和經驗，將運維監控視角由“傳統的分層+機器為中心”轉變為“以服務為中心”，設計并搭建了新一代云原生一體化運維監控系統（Bomc），保障了系統穩定，提升了監控運維效率。

二、新一代云原生一體化運維監控系統設計

2.1開源技術選型

2.1.1容器技術

容器技術可以理解為輕量級的虛擬化技術，但容器不等同于虛擬機，兩者之間有著本質的差別。相比虛擬機技術，容器并沒有虛擬化整個操作系統，而是在不同的虛擬化環境間共用同一個操作系統的內核，通過內核和相關工具集提供的功能，實現資源的隔離，包括：CPU、內存資源的隔離；磁盤I/O的隔離；網絡的隔離；用戶的隔離。本文設計的一體化運維監控系統使用的容器技術方案是Docker項目，Docker項目擁有標準化的鏡像機制、完善的API，和成熟的社區支持，是目前最為成熟穩定的容器技術產品。

2.1.2微鏡像技術

容器是一個運行時環境，容器得以運行的基礎是容器鏡像。微鏡像，是指由本文設計的監控系統構建出來的鏡像，其體積很小，相比市面上動輒上GB的容器鏡像，本監控系統的基礎鏡像平均在300MB左右。通過對鏡像尺寸的不斷壓縮和裁剪，可以在項目中減少不必要的網絡與存儲開銷，使得獲取鏡像的過程更加的方便、快捷，業務程序的更新也更加迅捷，大大有利于項目進度的快速推進。

2.2 技術方案

2.2.1基礎平臺設計

1.一鍵部署。1）平臺本身的一鍵部署。運營商業務的承載平臺擁有專業而強大的功能，其部署也較為復雜，通常需要專業技術人員親臨現場部署，或項目參與人員花大量時間進行學習，這就間接提高了項目的成本。一體化平臺在進行安裝時僅需執行一條命令，之后的過程自動化進行，且無需依賴任何特定的網絡環境，同時對進行部署的技術人員幾乎沒有技術要求，大大縮短了部署周期。2）業務程序的一鍵部署。一體化平臺在項目的開發、部署、測試、上線等環節，采用了持續集成的方式。基于Docker項目的容器技術，一體化平臺在進行產品發布的時候，保證了產品程序依賴的獨立性和完整性。在建立標準產品容器鏡像的基礎上，僅需在一體化平臺上拖拽拓撲圖標，便可一鍵部署業務程序。

2.多層監控。一體化平臺可對項目中的基礎硬件設施、通用組件和項目業務進行統一的多層監控。1）基礎硬件設施。通過對基礎硬件設施的抽象，可對傳統的物理服務器、虛擬服務器、網絡設備、存儲設備等硬件進行統一監控，通過代理程序（Agent），或者使用標準的SNMP等協議，可以便捷地獲取硬件的性能信息，并通過直觀的圖形化方式展現給運維管理人員。2）通用組件。一體化平臺對運營商業務平臺使用的通用組件進行了深入的研究，以獲取其準確的、能夠反映組件運行狀態的性能指標，通過一體化平臺對組件性能指標數據的采集和展示，可以客觀有效地反映出組件的運行狀態，有效地協助運維人員定位和分析問題。3）項目業務。在傳統運營商項目中，項目業務的監控是一個難點，往往需要編寫額外的獨立腳本或程序進行業務數據的獲取，而一體化平臺很巧妙地結合容器技術和日志清洗功能，將項目業務產生的監控日志直接采集到一體化平臺內部，并提供統一的監控展示。

3.高效運維。本文設計的一體化運維監控系統支持告警通知和通知方式相分離：這使得一個告警來源可以觸發多種通知方式，如短信、郵件、日志等（短信接口視項目的不同須定制開發），告警的時效得到進一步保障；支持實現彈性擴容的自動化操作、云資源的整合，以及故障處理的記錄。

2.2.2創新能力設計

本文基于運維數據，引入相關性計算、知識圖譜等AI技術，挖掘分析歷史性能、告警、調用鏈等運維數據，構建機器指標分層定界、業務指標多維分析、云原生故障分析樹等云原生排障能力，綜合應用，輔助實現云原生架構下的故障快速定界。

1.構建運維知識圖譜，排障基礎支撐。基于圖數據庫，構建運維知識圖譜，系統動態畫像。以應用為核心，動態串聯基礎設施和上層應用，實時呈現系統中的實體、關系和屬性。構建中臺化應用的動態監控、故障排查等運維場景的基礎能力。

2.機器指標分層定界分析，系統故障分層定界。業務出現故障時，應用智能算法基于業務所依賴的各集群、模塊和服務器的監控數據自動快速進行故障定位。通過對比監控數據在業務故障時間點前后相關機器指標的異常程度，并依據異常程度進行聚類排序展示，輔助快速確定故障排障方向。

3.業務明細多維定位，業務應用異常定界。基于故障業務系統異常時間段的大量交易明細，分多種維度（或組合維度）進行統計分析，根據維度組合告警前后的指標劣化程度進行排序展示，最終確定異常維度組合， 解決多維度或復雜組合維度下人工分析定位效率低的問題。

4.構建故障分析樹，進行故障溯源定位。依據云原生運維圖譜相關實體的屬性信息關聯故障時間段系統的異常信息，動態生成故障排障分析樹，并依據故障傳播圖拓撲結構及權值信息計算節點的根因概率并給出TOP根源推薦，輔助運維人員實現復雜調用及依賴關系下故障的快速定位排查。

三、應用場景及成效

本文設計的一體化運維監控系統應用成效主要體現在以下三個方面：

運維效率提升方面：云原生架構下，MTTR降低50%；隱患發現提前25分鐘，感知類故障降低31%；故障定位定界效率提升43%。

保障服務質量方面：智能運維提升系統運行穩定性，改善一線支撐感知，有效提升內外部客戶滿意度。

降低運維成本方面：通過生產系統的故障智能定界，每年節約各類工作量約8人月，按照代維成本1.8萬元/人月計算，全年節約約8*1.8*12=172萬元。

具體項目應用方面：

1. CRM容器化揚州中心、無錫中心基礎設施監控。實現CRM系統揚州中心、無錫中心2個資源池，180節點（宿主機），142個Kubernetes組件，101個應用、2525個Pod的動態發現和監控點自動配置及健康度、運行狀態、資源使用情況等的監控。實現按照應用、實例、命名空間多維度的查詢分析每個資源池中各容器化應用的資源使用情況，能夠按照應用、實例維度展示計算、網絡、存儲的綜合指標。

2.實現容器化營業廳零售系統應用性能及服務調用追蹤分析。完成營業廳零售系統會員管理、門店管理、優惠券管理、訂單管理等5個核心模塊部署，涉及26個應用Pod，每天近583萬次服務調用中各服務請求總數、請求處理時延、請求結果（成功、失敗）統計、調用結果（成功、失?。┙y計的監控，并提供了提供豐富的應用性能展示及性能問題定位功能，包括應用服務拓撲，服務間的調用關系、響應時間、吞吐量和狀態的展示，慢響應和錯誤明細的查詢，方便運維人員定位應用性能瓶頸。

參" 考" 文" 獻

[1]李濟偉.基于大數據平臺的自動化運維及監控技術研究[J].科技創新與應用，2021（11）：152-154.

[2]馬雄.基于微服務架構的系統設計與開發[D].南京郵電大學.

[3]張鼎超，等.面向高性能計算環境的微服務運維平臺設計與實現[J].計算機應用研究，2020，37（S2）：190-192.

[4]薛龍，等.面向云原生的智能運維架構和關鍵技術[J].電信科學， 2020，36（12）：105-122.