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

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

本文內容有三點：

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

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

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

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

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

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

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

多：互聯網用戶量巨大，達***在線量；

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

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

省：硬件成本增漲要低于用戶量增漲速度。

 

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

平臺擴展能力

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

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

平臺上的擴展“巨石架構”可以適應，但是功能上的擴展卻比較難適應。

功能擴展能力

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

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

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

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

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

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

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

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

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

是什么支撐運維平臺作為一個互聯網應用？——內存、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，核心的流程控制還是需要我們去建設的。

本文轉自雷鋒網，如需轉載請至雷鋒網官網申請授權。