0
| 本文作者： 優(yōu)維科技 | 2017-05-26 12:12 |
雷鋒網(wǎng)編者按：本文為優(yōu)維科技CTO黎明在《云上運(yùn)維與研發(fā)最佳實(shí)踐》活動(dòng)上的內(nèi)容分享，本文結(jié)合微服務(wù)架構(gòu)特點(diǎn)，解讀如何構(gòu)建一個(gè)高效運(yùn)維管理平臺。
黎明帶領(lǐng)團(tuán)隊(duì)自主研發(fā)了全棧DevOps運(yùn)維管理平臺—EasyOps，是目前行業(yè)領(lǐng)先的智能化運(yùn)維管理平臺。作為前騰訊運(yùn)維研發(fā)負(fù)責(zé)人，黎明主導(dǎo)了多個(gè)運(yùn)維系統(tǒng)研發(fā)輿情監(jiān)控、大數(shù)據(jù)監(jiān)控平臺、CMDB、實(shí)時(shí)日志分析平臺、織云、客戶端體驗(yàn)監(jiān)控等。
本文內(nèi)容有三點(diǎn)：
1、微服務(wù)架構(gòu)特點(diǎn)及其傳統(tǒng)巨石架構(gòu)的差異，以及傳統(tǒng)運(yùn)維工具面臨的挑戰(zhàn)；
2、面向微服務(wù)的運(yùn)維平臺架構(gòu)；
3、運(yùn)維平臺微服務(wù)進(jìn)化。
“微服務(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)用戶量巨大，達(dá)百萬級在線量；
快：服務(wù)請求反應(yīng)速度要在一秒以內(nèi)甚至更快；
好：服務(wù)質(zhì)量穩(wěn)定性要高；
?。河布杀驹鰸q要低于用戶量增漲速度。
△ 巨石架構(gòu)
如何解決這四個(gè)問題——增強(qiáng)整個(gè)平臺的靈活性。
△ 系統(tǒng)的擴(kuò)展
平臺擴(kuò)展能力
1.平行擴(kuò)展：一般的無狀態(tài)服務(wù)器可以通過服務(wù)器擴(kuò)容完成平行擴(kuò)展；
2.分區(qū)：對于有狀態(tài)的服務(wù)可以通過分區(qū)增強(qiáng)平臺靈活性，如：南北方用戶分屬A、B不同集群。
平臺上的擴(kuò)展“巨石架構(gòu)”可以適應(yīng)，但是功能上的擴(kuò)展卻比較難適應(yīng)。
功能擴(kuò)展能力
功能維度上，如何使系統(tǒng)變得更融洽？
1.靈活控制成本：局部調(diào)整，變更模塊、邏輯，而不是整個(gè)系統(tǒng)去修改。
巨石架構(gòu)的所有模塊都捆綁在一起，進(jìn)行擴(kuò)展時(shí)，由于每個(gè)模塊巨大，只能高成本平行整體擴(kuò)容。
微服務(wù)架構(gòu)下模塊產(chǎn)品的服務(wù)器分布非常靈活，擴(kuò)容成本低，現(xiàn)在都會(huì)選擇將服務(wù)器模塊切分，進(jìn)行微服務(wù)化改造，提升平臺支撐能力。
上文講述了微服務(wù)架構(gòu)與巨石架構(gòu)的差異，接下來了解如何構(gòu)建一個(gè)運(yùn)維管理平臺。
運(yùn)維平臺管理最重要的是應(yīng)用。對于應(yīng)用運(yùn)維來說，系統(tǒng)的前端所接入的官網(wǎng)、中間的邏輯服務(wù)，后端的存儲、緩存，分屬于不同的運(yùn)維。
把運(yùn)維平臺拆分成三塊具體化部件對應(yīng)到工作中。
運(yùn)維平臺的內(nèi)部應(yīng)用、內(nèi)部依賴是什么？——程序、配置文件、計(jì)算的資源
是什么支撐運(yùn)維平臺作為一個(gè)互聯(lián)網(wǎng)應(yīng)用？——內(nèi)存、CPU
運(yùn)維平臺依賴的資源有哪些？——系統(tǒng)鏡像
這是CMDB IT資源管理系統(tǒng)要承載的，在自動(dòng)化擴(kuò)容、環(huán)境部署時(shí)，只有了解這些數(shù)據(jù)，上層系統(tǒng)才知道如何構(gòu)建這個(gè)應(yīng)用。很多運(yùn)維團(tuán)隊(duì)，僅僅做到“工具化”，卻沒有跟“資源管理配置”聯(lián)動(dòng)起來。
資源有效管理之后，是研發(fā)、運(yùn)維這類的動(dòng)作管理。如：版本更新，遷移服務(wù)、搭建測試環(huán)境等標(biāo)準(zhǔn)化的動(dòng)作。
在擁有資源和動(dòng)作，達(dá)成自動(dòng)化運(yùn)維的閉環(huán)后。運(yùn)維人員只需事前維護(hù)好準(zhǔn)確的資源配置數(shù)據(jù)（CMDB），余下動(dòng)作系統(tǒng)會(huì)自驅(qū)完成。如果把資源跟動(dòng)作相混雜，每次運(yùn)用都需要耗費(fèi)資源定制專用的發(fā)布腳本、構(gòu)建腳本。
除了資源跟動(dòng)作管理，還有狀態(tài)（監(jiān)控）管理。每個(gè)公司都會(huì)有“監(jiān)控”系統(tǒng)。這里需要強(qiáng)調(diào)的是意識的問題，因?yàn)樵谡麄€(gè)上層、應(yīng)用層監(jiān)控設(shè)計(jì)中考慮了“自動(dòng)容災(zāi)切換”能力，所以我們不需要關(guān)注底層的監(jiān)控。只要應(yīng)用層沒有告警，不用管底層服務(wù)器和機(jī)房是否掛掉。
我剛參加工作時(shí)，系統(tǒng)經(jīng)常告警，需要半夜爬起來重啟機(jī)器、刪文件?，F(xiàn)在運(yùn)維只會(huì)接到通知，告知服務(wù)器掛掉，進(jìn)行確認(rèn)，不用實(shí)時(shí)處理?；谶@個(gè)邏輯，在業(yè)務(wù)沒有告警的情況下，我們系統(tǒng)就是正常的。
完善的運(yùn)維管理平臺能夠合理的把資源、動(dòng)作、狀態(tài)協(xié)調(diào)管理。
這張圖將上面那張簡單的圖做了擴(kuò)展、細(xì)分。
最上面是面向運(yùn)維，包含運(yùn)維、研發(fā)者的服務(wù)目錄和日常任務(wù)中心、狀態(tài)中心的統(tǒng)一運(yùn)維門戶。
下面是調(diào)度編排系統(tǒng)，產(chǎn)品擴(kuò)展根據(jù)不同行業(yè)及其業(yè)務(wù)特性，做出不同編排需求，將這些不同的需求選項(xiàng)進(jìn)行固化。
中間是運(yùn)維平臺的核心，執(zhí)行層的系統(tǒng)。忽略灰色的傳統(tǒng)API模塊，現(xiàn)在我們運(yùn)維日常使用的就是這個(gè)包括持續(xù)交付平臺、統(tǒng)一監(jiān)控平臺和ITOA運(yùn)營分析平臺在內(nèi)的立體化監(jiān)控系統(tǒng)，通過它實(shí)現(xiàn)動(dòng)作、狀態(tài)管理。針對基礎(chǔ)設(shè)施、平臺系統(tǒng)、應(yīng)用級、服務(wù)級甚至更高層的需求，提供精確度、優(yōu)先級不同的接口。
底層是CMDB資源管理。傳統(tǒng)CMDB管理對象，屬于硬件資產(chǎn)。在云化技術(shù)發(fā)展之后，會(huì)越來越弱化。應(yīng)用運(yùn)維就不需要關(guān)注太多。這里CMDB包含了業(yè)務(wù)信息管理、應(yīng)用程序包、配置、定時(shí)調(diào)度任務(wù)、流程、工具、權(quán)限、系統(tǒng)配置等基礎(chǔ)資源。
伴隨著公司業(yè)務(wù)的發(fā)展，如何將正在應(yīng)用的系統(tǒng)進(jìn)行架構(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)。比如我們的平臺運(yùn)用了Python、JAVA、PHP等語言，必須選擇同時(shí)兼容多種語言的協(xié)議。就像我們之前選用protobuf時(shí)，發(fā)現(xiàn)Python自帶的庫兼容Linux系統(tǒng)不成熟。在不同場景下，微服務(wù)的技術(shù)選型需要有較強(qiáng)的兼容性。
其次是語言的選擇。微服務(wù)強(qiáng)調(diào)接口的穩(wěn)定性，在保證服務(wù)穩(wěn)定的情況下，可以自由選擇熟悉的語言。
2.微服務(wù)的規(guī)劃
單一職責(zé)原則：每個(gè)服務(wù)應(yīng)該負(fù)責(zé)該功能的一個(gè)單獨(dú)的部分。
明確發(fā)布接口：每個(gè)服務(wù)都會(huì)發(fā)布定義明確的接口，而且保持不變，消費(fèi)者只關(guān)心接口而對于被消費(fèi)的服務(wù)沒有任何運(yùn)行依賴；
獨(dú)立部署、升級、擴(kuò)展和替換：每個(gè)服務(wù)都可以單獨(dú)部署及重新部署而不影響整個(gè)系統(tǒng)，這使得服務(wù)很容易升級與擴(kuò)展。
3. 平臺構(gòu)建
通過下面的兩個(gè)模塊來講解平臺的架構(gòu)。
1） CMDB系統(tǒng)怎樣做簡單的分拆，使之更容易維護(hù)？
CMDB是一個(gè)有大量配置系統(tǒng)存在的可以進(jìn)行查詢、修改的數(shù)據(jù)庫管理系統(tǒng)，它的內(nèi)部包含模型管理，配置管理、自動(dòng)發(fā)現(xiàn)。
A）模型管理
CMDB中，我們會(huì)管理大量隨著產(chǎn)品技術(shù)站演進(jìn)動(dòng)態(tài)變化的資源和相異的動(dòng)作，所以要獨(dú)立出模型管理的模塊，保證CMDB動(dòng)態(tài)可調(diào)整。
B）配置管理
由于CMDB的信息敏感度高，很多公司要求，將敏感業(yè)務(wù)信息，特別是應(yīng)用和IP這類關(guān)聯(lián)關(guān)系的信息保存在里面。
C）自動(dòng)發(fā)現(xiàn)
如果CMDB沒有完善的自動(dòng)發(fā)現(xiàn)機(jī)制，它失敗的概率會(huì)非常高。就像傳統(tǒng)CMDB有一個(gè)在嚴(yán)謹(jǐn)?shù)膶徟鷻C(jī)制運(yùn)行下的配置變更流程。但是即使在配置跟現(xiàn)網(wǎng)一致的情況下，還是需要每半年進(jìn)行一次資產(chǎn)盤整，對信息進(jìn)行糾正。對于有海量業(yè)務(wù)的系統(tǒng)來說，沒有“自動(dòng)發(fā)現(xiàn)”能力的CMDB是不合格的
通過“自動(dòng)發(fā)現(xiàn)”，去自動(dòng)化采集服務(wù)器帶寬、網(wǎng)卡速度、內(nèi)存、磁盤空間、進(jìn)程等信息，由CMDB進(jìn)行管理。模塊管理相對傳統(tǒng)，“自動(dòng)發(fā)現(xiàn)”是CMDB的核心，在同時(shí)管理數(shù)十萬臺服務(wù)器時(shí)，只能通過“自動(dòng)發(fā)現(xiàn)”的探偵才能進(jìn)行自動(dòng)化維護(hù)。
2） 持續(xù)部署系統(tǒng)
持續(xù)部署系統(tǒng)負(fù)責(zé)自動(dòng)化發(fā)布。上圖將持續(xù)部署系統(tǒng)的平臺構(gòu)建分為多個(gè)子模塊。
A） 構(gòu)建管理
構(gòu)建即以靜態(tài)圖片、業(yè)務(wù)程序、配置文件等為主的部署對象。根據(jù)DevOps中的原則，需要將一切版本化。所以需要一個(gè)構(gòu)建庫負(fù)責(zé)管理所有發(fā)布到生產(chǎn)環(huán)境的資源。
通過統(tǒng)一的構(gòu)建庫，對所有發(fā)布到線網(wǎng)上的數(shù)據(jù)進(jìn)行標(biāo)準(zhǔn)化管理，以此可以快速在其他機(jī)房重建原系統(tǒng)等。同時(shí)它還擁有信息共享功能，過去運(yùn)維發(fā)包之后跟蹤困難，現(xiàn)在研發(fā)人員只需向構(gòu)建庫輸入版本信息，運(yùn)維從構(gòu)建庫中導(dǎo)出就好了。
B） 任務(wù)管理
任務(wù)庫負(fù)責(zé)存儲日常發(fā)布任務(wù)，滿足自動(dòng)化發(fā)布需求。曾經(jīng)由于很多研發(fā)人員貪圖方便，選擇在現(xiàn)網(wǎng)直接更改系統(tǒng)，記錄信息錯(cuò)亂變更很不利于任務(wù)管理的日常下發(fā)。
常常是錯(cuò)誤的，所以我們并不使用“任務(wù)下發(fā)完成之后，系統(tǒng)設(shè)置自動(dòng)更新”這種設(shè)計(jì)。在無法信任上層管理系統(tǒng)的情況下，現(xiàn)網(wǎng)信息、數(shù)據(jù)必須實(shí)時(shí)掃描上報(bào)。
為了保證信息的發(fā)布成功，必須以Agent上報(bào)的信息為準(zhǔn)。因?yàn)榕渲眯畔⒋嬖诖罅孔兏肟冢跓o法保證唯一入口的情況下，不能想當(dāng)然的設(shè)計(jì)系統(tǒng)。
命令通道與數(shù)據(jù)通道是除了構(gòu)建庫、任務(wù)庫、實(shí)例庫之外的上層系統(tǒng)的基本構(gòu)成。首先命令通道與數(shù)據(jù)通道需要分開管理。騰訊曾經(jīng)需要將1G的文件發(fā)送到兩千臺服務(wù)器，頻率達(dá)到一周一次，一次一周，不斷重試、失敗。后來將命令與數(shù)據(jù)切開，每次只傳輸幾十K的命令腳本，服務(wù)器再也沒有阻塞。
開源方案部分問題依舊無法解決，像現(xiàn)在的異構(gòu)網(wǎng)絡(luò)，在混合云的場景下，必須保證網(wǎng)絡(luò)互通，才能做到直連。大家可以選擇自己去編寫Agent練手，通過反向通道連接中心管理服務(wù)器去解決此問題。
1.名字服務(wù)
名字服務(wù)指通過配置文件中匹配的名字查IP端口的服務(wù)，可以選擇合適的開源方案。如果自研的話，可以對服務(wù)進(jìn)行靈活分區(qū)等。如深圳的服務(wù)器A訪問在深圳、上海兩地均部署服務(wù)的B，我們只需要在，名字服務(wù)中與CMDB打通，使用深圳的服務(wù)器訪問深圳的IP，達(dá)到同城訪問的效果。這個(gè)操作在開源方案中就無法完美實(shí)現(xiàn)。
2. 狀態(tài)監(jiān)控
要求能達(dá)到接口即調(diào)用數(shù)據(jù)采集的應(yīng)用層監(jiān)控。
通過訪問量、成功率、平均時(shí)延這三個(gè)核心指標(biāo)，低成本把握絕大部分需求。以訪問量為例，當(dāng)訪問失敗率上升告警時(shí)，直接觸發(fā)名字服務(wù)聯(lián)動(dòng)，將故障節(jié)點(diǎn)自動(dòng)摘除。
3.負(fù)載均衡
當(dāng)系統(tǒng)規(guī)模擴(kuò)大，節(jié)點(diǎn)劇增時(shí)，增加中間代理的方法會(huì)增加系統(tǒng)內(nèi)部壓力。
如果落地到Agent，通過名字服務(wù)查詢IP列表，合并狀態(tài)信息，均衡節(jié)點(diǎn)請求，可以更好的達(dá)到負(fù)載均衡。
負(fù)載均衡的極端就是容災(zāi)，正常情況下根據(jù)性能狀況保證每個(gè)節(jié)點(diǎn)處理合適的請求量即可。
這三點(diǎn)是運(yùn)維平臺或業(yè)務(wù)生產(chǎn)的系統(tǒng)中的核心能力。包括騰訊在內(nèi)的運(yùn)維平臺都是基于這三個(gè)服務(wù)閉環(huán)去運(yùn)行的。只有在做到這三點(diǎn)，才能解決系統(tǒng)異常，維持系統(tǒng)的正常運(yùn)轉(zhuǎn)。
其實(shí)我們在平臺構(gòu)建的時(shí)候，在整個(gè)的平臺進(jìn)化的過程中，其實(shí)是要有優(yōu)先級，要有取舍的?？偟脕碚f，優(yōu)先要解決我們的瓶頸問題。 然后是平行擴(kuò)展的能力，還有考慮服務(wù)復(fù)用的能力，甚至是一些開源的解決方案的利用。但是開源這個(gè)東西，我從來不覺得是說大家把一堆的開源工具用在一起，能夠形成一個(gè)很好的一個(gè)運(yùn)維平臺。
大家應(yīng)該是把這些開源的能力，這些一個(gè)個(gè)的微服務(wù)，核心的這個(gè)架構(gòu)還是必須要有自己的控制力在這里。比如：監(jiān)控。很多開源的系統(tǒng)，它是更偏重于執(zhí)行層的工具，但是核心的CMDB，核心的流程控制還是需要我們?nèi)ソㄔO(shè)的。
雷峰網(wǎng)原創(chuàng)文章，未經(jīng)授權(quán)禁止轉(zhuǎn)載。詳情見轉(zhuǎn)載須知。
