如何在微服務架構下構建高效的運維管理平台？

知識 05-27

AI研習社按：本文為優維科技 CTO 黎明在《雲上運維與研發最佳實踐》活動上的內容分享，本文結合微服務架構特點，解讀如何構建一個高效運維管理平台。

黎明帶領團隊自主研發了全棧 DevOps 運維管理平台—EasyOps，是目前行業領先的智能化運維管理平台。作為前騰訊運維研發負責人，黎明主導了多個運維繫統研發輿情監控、大數據監控平台、CMDB、實時日誌分析平台、織雲、客戶端體驗監控等。

本文內容有三點：

1、微服務架構特點及其傳統巨石架構的差異，以及傳統運維工具面臨的挑戰；

2、面向微服務的運維平台架構；

3、運維平台微服務進化。

一、微服務架構與巨石架構的差異

「微服務」與「巨石架構」兩者並非對立，而是分別針對不同場景的解決方案。

巨石架構指將所有「大腦」集中在一起，以 CS 架構為代表，將所有的邏輯放在唯一應用中，再加入前端 UI 組件、Service、MVC 架構、資料庫等部分。它的技術架構不複雜，調試、部署、管理方便，是適用於絕大部分系統的解決方案。

但是在互聯網要求「多、快、好、省」的應用場景下，「巨石架構」面臨諸多挑戰。

多：互聯網用戶量巨大，達百萬級在線量；

快：服務請求反應速度要在一秒以內甚至更快；

好：服務質量穩定性要高；

省：硬體成本增漲要低於用戶量增漲速度。

巨石架構

如何解決這四個問題——增強整個平台的靈活性。

系統的擴展

平台擴展能力

1. 平行擴展：一般的無狀態伺服器可以通過伺服器擴容完成平行擴展；

2. 分區：對於有狀態的服務可以通過分區增強平台靈活性，如：南北方用戶分屬 A、B 不同集群。

平台上的擴展「巨石架構」可以適應，但是功能上的擴展卻比較難適應。

功能擴展能力

功能維度上，如何使系統變得更融洽？

靈活控制成本：局部調整，變更模塊、邏輯，而不是整個系統去修改。

巨石架構的所有模塊都捆綁在一起，進行擴展時，由於每個模塊巨大，只能高成本平行整體擴容。

微服務架構下模塊產品的伺服器分布非常靈活，擴容成本低，現在都會選擇將伺服器模塊切分，進行微服務化改造，提昇平台支撐能力。

二、微服務架構下如何構建一個運維管理平台

上文講述了微服務架構與巨石架構的差異，接下來了解如何構建一個運維管理平台。

運維平台管理最重要的是應用。對於應用運維來說，系統的前端所接入的官網、中間的邏輯服務，後端的存儲、緩存，分屬於不同的運維。

把運維平台拆分成三塊具體化部件對應到工作中。

運維平台的內部應用、內部依賴是什麼？——程序、配置文件、計算的資源

是什麼支撐運維平台作為一個互聯網應用？——內存、CPU

運維平台依賴的資源有哪些？——系統鏡像

這是 CMDB IT 資源管理系統要承載的，在自動化擴容、環境部署時，只有了解這些數據，上層系統才知道如何構建這個應用。很多運維團隊，僅僅做到「工具化」，卻沒有跟「資源管理配置」聯動起來。

資源有效管理之後，是研發、運維這類的動作管理。如：版本更新，遷移服務、搭建測試環境等標準化的動作。

在擁有資源和動作，達成自動化運維的閉環後。運維人員只需事前維護好準確的資源配置數據（CMDB），餘下動作系統會自驅完成。如果把資源跟動作相混雜，每次運用都需要耗費資源定製專用的發布腳本、構建腳本。

除了資源跟動作管理，還有狀態（監控）管理。每個公司都會有「監控」系統。這裡需要強調的是意識的問題，因為在整個上層、應用層監控設計中考慮了「自動容災切換」能力，所以我們不需要關注底層的監控。只要應用層沒有告警，不用管底層伺服器和機房是否掛掉。

我剛參加工作時，系統經常告警，需要半夜爬起來重啟機器、刪文件。現在運維只會接到通知，告知伺服器掛掉，進行確認，不用實時處理。基於這個邏輯，在業務沒有告警的情況下，我們系統就是正常的。

完善的運維管理平台能夠合理的把資源、動作、狀態協調管理。

這張圖將上面那張簡單的圖做了擴展、細分。

最上面是面向運維，包含運維、研發者的服務目錄和日常任務中心、狀態中心的統一運維門戶。

下面是調度編排系統，產品擴展根據不同行業及其業務特性，做出不同編排需求，將這些不同的需求選項進行固化。

中間是運維平台的核心，執行層的系統。忽略灰色的傳統 API 模塊，現在我們運維日常使用的就是這個包括持續交付平台、統一監控平台和 ITOA 運營分析平台在內的立體化監控系統，通過它實現動作、狀態管理。針對基礎設施、平台系統、應用級、服務級甚至更高層的需求，提供精確度、優先順序不同的介面。

底層是 CMDB 資源管理。傳統 CMDB 管理對象，屬於硬體資產。在雲化技術發展之後，會越來越弱化。應用運維就不需要關注太多。這裡 CMDB 包含了業務信息管理、應用程序包、配置、定時調度任務、流程、工具、許可權、系統配置等基礎資源。

三、運維平台的微服務進化

伴隨著公司業務的發展，如何將正在應用的系統進行架構上的優化或者規劃？

1. 技術選型

首先，微服務跟基礎架構的區別在於，微服務的組件拆分後是通過網路傳輸的。因此通訊標準要做出合理的選型。

微服務的架構，通常是異構架構。比如我們的平台運用了 Python、JAVA、PHP 等語言，必須選擇同時兼容多種語言的協議。就像我們之前選用 protobuf 時，發現 Python 自帶的庫兼容 Linux 系統不成熟。在不同場景下，微服務的技術選型需要有較強的兼容性。

其次是語言的選擇。微服務強調介面的穩定性，在保證服務穩定的情況下，可以自由選擇熟悉的語言。

2. 微服務的規劃

單一職責原則：每個服務應該負責該功能的一個單獨的部分。

明確發布介面：每個服務都會發布定義明確的介面，而且保持不變，消費者只關心介面而對於被消費的服務沒有任何運行依賴；

獨立部署、升級、擴展和替換：每個服務都可以單獨部署及重新部署而不影響整個系統，這使得服務很容易升級與擴展。

3. 平台構建

通過下面的兩個模塊來講解平台的架構。

1） CMDB 系統怎樣做簡單的分拆，使之更容易維護？

CMDB 是一個有大量配置系統存在的可以進行查詢、修改的資料庫管理系統，它的內部包含模型管理，配置管理、自動發現。

A）模型管理

CMDB 中，我們會管理大量隨著產品技術站演進動態變化的資源和相異的動作，所以要獨立出模型管理的模塊，保證 CMDB 動態可調整。

B）配置管理

由於 CMDB 的信息敏感度高，很多公司要求，將敏感業務信息，特別是應用和 IP 這類關聯關係的信息保存在裡面。

C）自動發現

如果 CMDB 沒有完善的自動發現機制，它失敗的概率會非常高。就像傳統 CMDB 有一個在嚴謹的審批機制運行下的配置變更流程。但是即使在配置跟現網一致的情況下，還是需要每半年進行一次資產盤整，對信息進行糾正。對於有海量業務的系統來說，沒有「自動發現」能力的 CMDB 是不合格的

通過「自動發現」，去自動化採集伺服器帶寬、網卡速度、內存、磁碟空間、進程等信息，由 CMDB 進行管理。模塊管理相對傳統，「自動發現」是 CMDB 的核心，在同時管理數十萬台伺服器時，只能通過「自動發現」的探偵才能進行自動化維護。

2）持續部署系統

持續部署系統負責自動化發布。上圖將持續部署系統的平台構建分為多個子模塊。

A）構建管理

構建即以靜態圖片、業務程序、配置文件等為主的部署對象。根據 DevOps 中的原則，需要將一切版本化。所以需要一個構建庫負責管理所有發布到生產環境的資源。

通過統一的構建庫，對所有發布到線網上的數據進行標準化管理，以此可以快速在其他機房重建原系統等。同時它還擁有信息共享功能，過去運維發包之後跟蹤困難，現在研發人員只需向構建庫輸入版本信息，運維從構建庫中導出就好了。

B）任務管理

任務庫負責存儲日常發布任務，滿足自動化發布需求。曾經由於很多研發人員貪圖方便，選擇在現網直接更改系統，記錄信息錯亂變更很不利於任務管理的日常下發。

常常是錯誤的，所以我們並不使用「任務下發完成之後，系統設置自動更新」這種設計。在無法信任上層管理系統的情況下，現網信息、數據必須實時掃描上報。

為了保證信息的發布成功，必須以 Agent 上報的信息為準。因為配置信息存在大量變更入口，在無法保證唯一入口的情況下，不能想當然的設計系統。

命令通道與數據通道是除了構建庫、任務庫、實例庫之外的上層系統的基本構成。首先命令通道與數據通道需要分開管理。騰訊曾經需要將 1G 的文件發送到兩千台伺服器，頻率達到一周一次，一次一周，不斷重試、失敗。後來將命令與數據切開，每次只傳輸幾十 K 的命令腳本，伺服器再也沒有阻塞。

開源方案部分問題依舊無法解決，像現在的異構網路，在混合雲的場景下，必須保證網路互通，才能做到直連。大家可以選擇自己去編寫 Agent 練手，通過反向通道連接中心管理伺服器去解決此問題。

三、微服務架構下平台架構的底層基礎服務

1. 名字服務

名字服務指通過配置文件中匹配的名字查 IP 埠的服務，可以選擇合適的開源方案。如果自研的話，可以對服務進行靈活分區等。如深圳的伺服器 A 訪問在深圳、上海兩地均部署服務的 B，我們只需要在，名字服務中與 CMDB 打通，使用深圳的伺服器訪問深圳的 IP，達到同城訪問的效果。這個操作在開源方案中就無法完美實現。

2. 狀態監控

要求能達到介面即調用數據採集的應用層監控。

通過訪問量、成功率、平均時延這三個核心指標，低成本把握絕大部分需求。以訪問量為例，當訪問失敗率上升告警時，直接觸發名字服務聯動，將故障節點自動摘除。

3. 負載均衡

當系統規模擴大，節點劇增時，增加中間代理的方法會增加系統內部壓力。

如果落地到 Agent，通過名字服務查詢 IP 列表，合并狀態信息，均衡節點請求，可以更好的達到負載均衡。

負載均衡的極端就是容災，正常情況下根據性能狀況保證每個節點處理合適的請求量即可。

這三點是運維平台或業務生產的系統中的核心能力。包括騰訊在內的運維平台都是基於這三個服務閉環去運行的。只有在做到這三點，才能解決系統異常，維持系統的正常運轉。

四、微服務運維平台的迭代重心

其實我們在平台構建的時候，在整個的平台進化的過程中，其實是要有優先順序，要有取捨的。總得來說，優先要解決我們的瓶頸問題。然後是平行擴展的能力，還有考慮服務復用的能力，甚至是一些開源的解決方案的利用。但是開源這個東西，我從來不覺得是說大家把一堆的開源工具用在一起，能夠形成一個很好的一個運維平台。

大家應該是把這些開源的能力，這些一個個的微服務，核心的這個架構還是必須要有自己的控制力在這裡。比如：監控。很多開源的系統，它是更偏重於執行層的工具，但是核心的 CMDB，核心的流程控制還是需要我們去建設的。

點擊展開全文