雷鋒網(wǎng)編者按：本文為優(yōu)維科技CTO黎明在《云上運維與研發(fā)最佳實踐》活動上的內(nèi)容分享，本文結(jié)合微服務(wù)架構(gòu)特點，解讀如何構(gòu)建一個高效運維管理平臺。 

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

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

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

2、面向微服務(wù)的運維平臺架構(gòu)；

3、運維平臺微服務(wù)進化。

一、 微服務(wù)架構(gòu)與巨石架構(gòu)的差異

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

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

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

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

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

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

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

△ 巨石架構(gòu)

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

△ 系統(tǒng)的擴展

平臺擴展能力

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

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

平臺上的擴展“巨石架構(gòu)”可以適應(yīng)，但是功能上的擴展卻比較難適應(yīng)。

功能擴展能力

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

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

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

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

二、微服務(wù)架構(gòu)下如何構(gòu)建一個運維管理平臺

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、運維平臺的微服務(wù)進化

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

1.技術(shù)選型

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

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

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

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

單一職責(zé)原則：每個服務(wù)應(yīng)該負(fù)責(zé)該功能的一個單獨的部分。

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

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

3. 平臺構(gòu)建

通過下面的兩個模塊來講解平臺的架構(gòu)。

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

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

A）模型管理

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

B）配置管理

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

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

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

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

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

 

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

A） 構(gòu)建管理

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

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

B） 任務(wù)管理

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

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

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

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

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

微服務(wù)架構(gòu)下平臺架構(gòu)的底層基礎(chǔ)服務(wù)   

1.名字服務(wù)

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

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

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

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

3.負(fù)載均衡

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

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

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

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

微服務(wù)運維平臺的迭代重心

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

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

雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。