如何構建一個高效的運維管理平臺？

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

黎明帶領團隊自主研發(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)定性要高拱镐；

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

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

平臺擴展能力

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)常告警剧防，需要半夜爬起來重啟機器、刪文件”栌＃現(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ù)摹Ｒ虼送ㄓ崢藴室龀龊侠淼倪x型剪撬。

微服務的架構摄乒，通常是異構架構。比如我們的平臺運用了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)的正常運轉(zhuǎn)唉侄。

微服務運維平臺的迭代重心
其實我們在平臺構建的時候，在整個的平臺進化的過程中野建，其實是要有優(yōu)先級属划，要有取舍的『蛏總得來說同眯，優(yōu)先要解決我們的瓶頸問題。 然后是平行擴展的能力唯鸭，還有考慮服務復用的能力须蜗，甚至是一些開源的解決方案的利用。但是開源這個東西目溉，我從來不覺得是說大家把一堆的開源工具用在一起明肮，能夠形成一個很好的一個運維平臺。

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

作者：庫克look
來源：CSDN
原文：https://blog.csdn.net/weixin_44195108/article/details/88309327