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

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

本文內(nèi)容有三點：

1、微服務架構特點及其傳統(tǒng)巨石架構的差異，以及傳統(tǒng)運維工具面臨的挑戰(zhàn)；

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

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

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

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

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

但是在互聯(lián)網(wǎng)要求“多、快、好、省”的應用場景下，“巨石架構”面臨諸多挑戰(zhàn)。

多：互聯(lián)網(wǎng)用戶量巨大，達***在線量；

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

好：服務質(zhì)量穩(wěn)定性要高；

?。河布杀驹鰸q要低于用戶量增漲速度。

 

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

平臺擴展能力

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

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

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

功能擴展能力

功能維度上，如何使系統(tǒng)變得更融洽？

1.靈活控制成本：局部調(diào)整，變更模塊、邏輯，而不是整個系統(tǒng)去修改。

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

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

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

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

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

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

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

是什么支撐運維平臺作為一個互聯(lián)網(wǎng)應用？——內(nèi)存、CPU

運維平臺依賴的資源有哪些？——系統(tǒng)鏡像

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

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

在擁有資源和動作，達成自動化運維的閉環(huán)后。運維人員只需事前維護好準確的資源配置數(shù)據(jù)（CMDB），余下動作系統(tǒng)會自驅(qū)完成。如果把資源跟動作相混雜，每次運用都需要耗費資源定制專用的發(fā)布腳本、構建腳本。

除了資源跟動作管理，還有狀態(tài)（監(jiān)控）管理。每個公司都會有“監(jiān)控”系統(tǒng)。這里需要強調(diào)的是意識的問題，因為在整個上層、應用層監(jiān)控設計中考慮了“自動容災切換”能力，所以我們不需要關注底層的監(jiān)控。只要應用層沒有告警，不用管底層服務器和機房是否掛掉。

我剛參加工作時，系統(tǒng)經(jīng)常告警，需要半夜爬起來重啟機器、刪文件?，F(xiàn)在運維只會接到通知，告知服務器掛掉，進行確認，不用實時處理。基于這個邏輯，在業(yè)務沒有告警的情況下，我們系統(tǒng)就是正常的。

完善的運維管理平臺能夠合理的把資源、動作、狀態(tài)協(xié)調(diào)管理。

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

最上面是面向運維，包含運維、研發(fā)者的服務目錄和日常任務中心、狀態(tài)中心的統(tǒng)一運維門戶。

下面是調(diào)度編排系統(tǒng)，產(chǎn)品擴展根據(jù)不同行業(yè)及其業(yè)務特性，做出不同編排需求，將這些不同的需求選項進行固化。

中間是運維平臺的核心，執(zhí)行層的系統(tǒng)。忽略灰色的傳統(tǒng)API模塊，現(xiàn)在我們運維日常使用的就是這個包括持續(xù)交付平臺、統(tǒng)一監(jiān)控平臺和ITOA運營分析平臺在內(nèi)的立體化監(jiān)控系統(tǒng)，通過它實現(xiàn)動作、狀態(tài)管理。針對基礎設施、平臺系統(tǒng)、應用級、服務級甚至更高層的需求，提供精確度、優(yōu)先級不同的接口。

底層是CMDB資源管理。傳統(tǒng)CMDB管理對象，屬于硬件資產(chǎn)。在云化技術發(fā)展之后，會越來越弱化。應用運維就不需要關注太多。這里CMDB包含了業(yè)務信息管理、應用程序包、配置、定時調(diào)度任務、流程、工具、權限、系統(tǒng)配置等基礎資源。

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

伴隨著公司業(yè)務的發(fā)展，如何將正在應用的系統(tǒng)進行架構上的優(yōu)化或者規(guī)劃？

1.技術選型

首先，微服務跟基礎架構的區(qū)別在于，微服務的組件拆分后是通過網(wǎng)絡傳輸?shù)?。因此通訊標準要做出合理的選型。

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

其次是語言的選擇。微服務強調(diào)接口的穩(wěn)定性，在保證服務穩(wěn)定的情況下，可以自由選擇熟悉的語言。

2.微服務的規(guī)劃

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

明確發(fā)布接口：每個服務都會發(fā)布定義明確的接口，而且保持不變，消費者只關心接口而對于被消費的服務沒有任何運行依賴；

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

3. 平臺構建

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

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

CMDB是一個有大量配置系統(tǒng)存在的可以進行查詢、修改的數(shù)據(jù)庫管理系統(tǒng)，它的內(nèi)部包含模型管理，配置管理、自動發(fā)現(xiàn)。

A）模型管理

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

B）配置管理

由于CMDB的信息敏感度高，很多公司要求，將敏感業(yè)務信息，特別是應用和IP這類關聯(lián)關系的信息保存在里面。

C）自動發(fā)現(xiàn)

如果CMDB沒有完善的自動發(fā)現(xiàn)機制，它失敗的概率會非常高。就像傳統(tǒng)CMDB有一個在嚴謹?shù)膶徟鷻C制運行下的配置變更流程。但是即使在配置跟現(xiàn)網(wǎng)一致的情況下，還是需要每半年進行一次資產(chǎn)盤整，對信息進行糾正。對于有海量業(yè)務的系統(tǒng)來說，沒有“自動發(fā)現(xiàn)”能力的CMDB是不合格的

通過“自動發(fā)現(xiàn)”，去自動化采集服務器帶寬、網(wǎng)卡速度、內(nèi)存、磁盤空間、進程等信息，由CMDB進行管理。模塊管理相對傳統(tǒng)，“自動發(fā)現(xiàn)”是CMDB的核心，在同時管理數(shù)十萬臺服務器時，只能通過“自動發(fā)現(xiàn)”的探偵才能進行自動化維護。

2） 持續(xù)部署系統(tǒng)

 

持續(xù)部署系統(tǒng)負責自動化發(fā)布。上圖將持續(xù)部署系統(tǒng)的平臺構建分為多個子模塊。

A） 構建管理

構建即以靜態(tài)圖片、業(yè)務程序、配置文件等為主的部署對象。根據(jù)DevOps中的原則，需要將一切版本化。所以需要一個構建庫負責管理所有發(fā)布到生產(chǎn)環(huán)境的資源。

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

B） 任務管理

任務庫負責存儲日常發(fā)布任務，滿足自動化發(fā)布需求。曾經(jīng)由于很多研發(fā)人員貪圖方便，選擇在現(xiàn)網(wǎng)直接更改系統(tǒng)，記錄信息錯亂變更很不利于任務管理的日常下發(fā)。

常常是錯誤的，所以我們并不使用“任務下發(fā)完成之后，系統(tǒng)設置自動更新”這種設計。在無法信任上層管理系統(tǒng)的情況下，現(xiàn)網(wǎng)信息、數(shù)據(jù)必須實時掃描上報。

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

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

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

微服務架構下平臺架構的底層基礎服務   

1.名字服務

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

2. 狀態(tài)監(jiān)控

要求能達到接口即調(diào)用數(shù)據(jù)采集的應用層監(jiān)控。

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

3.負載均衡

當系統(tǒng)規(guī)模擴大，節(jié)點劇增時，增加中間代理的方法會增加系統(tǒng)內(nèi)部壓力。

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

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

這三點是運維平臺或業(yè)務生產(chǎn)的系統(tǒng)中的核心能力。包括騰訊在內(nèi)的運維平臺都是基于這三個服務閉環(huán)去運行的。只有在做到這三點，才能解決系統(tǒng)異常，維持系統(tǒng)的正常運轉。

微服務運維平臺的迭代重心

其實我們在平臺構建的時候，在整個的平臺進化的過程中，其實是要有優(yōu)先級，要有取舍的?？偟脕碚f，優(yōu)先要解決我們的瓶頸問題。 然后是平行擴展的能力，還有考慮服務復用的能力，甚至是一些開源的解決方案的利用。但是開源這個東西，我從來不覺得是說大家把一堆的開源工具用在一起，能夠形成一個很好的一個運維平臺。

大家應該是把這些開源的能力，這些一個個的微服務，核心的這個架構還是必須要有自己的控制力在這里。比如：監(jiān)控。很多開源的系統(tǒng)，它是更偏重于執(zhí)行層的工具，但是核心的CMDB，核心的流程控制還是需要我們?nèi)ソㄔO的。

本文轉自雷鋒網(wǎng)，如需轉載請至雷鋒網(wǎng)官網(wǎng)申請授權。