一文看懂云原生時(shí)代 DevOps 如何選型
前? ? 言
今天的中國(guó)互聯(lián)網(wǎng)，正加速?gòu)南M(fèi)互聯(lián)網(wǎng)向產(chǎn)業(yè)互聯(lián)網(wǎng)轉(zhuǎn)型，數(shù)字化變革逐漸滲透到每一個(gè)具體產(chǎn)業(yè)，彈性算力已變成各行各業(yè)的水電煤，從底層驅(qū)動(dòng)產(chǎn)業(yè)變革。以區(qū)塊鏈、IoT、人工智能、大數(shù)據(jù)等先進(jìn)技術(shù)為代表，新的云原生基礎(chǔ)設(shè)施已經(jīng)就緒并將繼續(xù)演進(jìn)，同時(shí)也會(huì)伴隨著與之配套的技術(shù)和管理范式的演進(jìn)。DevOps 作為數(shù)字化時(shí)代 IT 研發(fā)和管理范式，是企業(yè)數(shù)字化轉(zhuǎn)型重要的組成部分。
當(dāng)前互聯(lián)網(wǎng)組件生態(tài)中，DevOps 工具和系統(tǒng)林林總總，令人眼花繚亂。選用與當(dāng)前企業(yè)發(fā)展階段不適配的 DevOps 組件會(huì)導(dǎo)致：
工具能力溢出，大量功能閑置，同時(shí)增加使用人員的上手成本；
工具能力不足或功能過(guò)于泛化，無(wú)法滿足企業(yè)研發(fā)體量需求或無(wú)法靈活定制細(xì)節(jié)；
工具本身質(zhì)量欠佳，后續(xù)相應(yīng)的社區(qū)支持或服務(wù)保障缺失，導(dǎo)致穩(wěn)定性風(fēng)險(xiǎn)。
基于以上問(wèn)題，本文致力于為企業(yè)提供 DevOps 工程效率和運(yùn)維環(huán)節(jié)（后續(xù)簡(jiǎn)稱效維）工具說(shuō)明及全景圖，并結(jié)合典型中國(guó)互聯(lián)網(wǎng)研發(fā)場(chǎng)景，提出適配不同體量和階段的企業(yè)的效維工具鏈選型，希望能幫助企業(yè)快速滿足數(shù)字化變革的要求，加速業(yè)務(wù)發(fā)展，引領(lǐng)業(yè)務(wù)創(chuàng)新。
DevOps 是 Development 和 Operations 的組合詞。它是一組過(guò)程、方法與系統(tǒng)的統(tǒng)稱，用于促進(jìn)開發(fā)（應(yīng)用程序 / 軟件工程）、技術(shù)運(yùn)營(yíng)和質(zhì)量保障（QA）部門之間的溝通、協(xié)作與整合。
圖 1 DevOps 范疇
它是一種重視“軟件開發(fā)人員（Dev）”和“IT 運(yùn)維技術(shù)人員（Ops）”之間溝通合作的文化、運(yùn)動(dòng)或慣例。透過(guò)自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程，來(lái)使得構(gòu)建、測(cè)試、發(fā)布軟件能夠更加地快捷、頻繁和可靠，把敏捷開發(fā)部門和運(yùn)維部門之間的圍墻打通，形成閉環(huán)。
在 DevOps 流程下，運(yùn)維人員會(huì)在項(xiàng)目開發(fā)期間就介入到開發(fā)過(guò)程中，了解開發(fā)人員使用的系統(tǒng)架構(gòu)和技術(shù)路線，從而制定適當(dāng)?shù)倪\(yùn)維方案。而開發(fā)人員也會(huì)在運(yùn)維的初期參與到系統(tǒng)部署中，并提供系統(tǒng)部署的優(yōu)化建議。
完整的 DevOps 生命周期一般包括以下六個(gè)階段。
圖 2 DevOps 生命周期
其中集成、部署、監(jiān)控三個(gè)環(huán)節(jié)屬于 DevOps 生命周期中核心環(huán)節(jié)，是本文主要關(guān)注點(diǎn)。貫穿云原生 DevOps 整個(gè)生命周期的工具鏈全景圖如下：
圖 3 云原生 DevOps 工具全景圖
持續(xù)集成可以幫助開發(fā)人員更加頻繁地（有時(shí)甚至每天）將代碼更改合并到共享分支或“主干"中。一旦開發(fā)人員對(duì)應(yīng)用所做的更改被合并，系統(tǒng)就會(huì)通過(guò)自動(dòng)構(gòu)建應(yīng)用并運(yùn)行不同級(jí)別的自動(dòng)化測(cè)試（通常是單元測(cè)試和集成測(cè)試）來(lái)驗(yàn)證這些更改，確保這些更改沒(méi)有對(duì)應(yīng)用造成破壞。持續(xù)集成的輸入是代碼，所以一個(gè)好的代碼托管工具是必不可少的。
持續(xù)部署指的的是自動(dòng)將開發(fā)人員的更改從存儲(chǔ)庫(kù)發(fā)布到生產(chǎn)環(huán)境，以供客戶使用。它主要為了解決因手動(dòng)流程降低應(yīng)用交付速度，從而使運(yùn)維團(tuán)隊(duì)超負(fù)荷的問(wèn)題。部署過(guò)程中可能還會(huì)涉及到平滑遷移新老版本流量的過(guò)程，所以對(duì)服務(wù)發(fā)現(xiàn)工具也有一定的依賴。
要實(shí)現(xiàn)持續(xù)集成和持續(xù)部署，自動(dòng)化的流水線是基礎(chǔ)。本節(jié)將從代碼托管工具、集成流水線工具、服務(wù)發(fā)現(xiàn)工具三個(gè)方面進(jìn)行工具對(duì)比介紹。
在選擇代碼托管工具的時(shí)候，主要關(guān)注以下三點(diǎn)：
可協(xié)同：在功能層面要包含倉(cāng)庫(kù)管理、分支管理、權(quán)限管理、提交管理、代碼評(píng)審等代碼存儲(chǔ)和版本管理等功能，讓開發(fā)者更好的協(xié)同工作；
可集成：好的代碼托管服務(wù)應(yīng)該具備靈活和簡(jiǎn)易的三方工具集成能力，降低 DevOps 的實(shí)施落地成本 ;
安全可靠：這是最重要的一點(diǎn)，對(duì)于個(gè)人開發(fā)者可能無(wú)感，但是對(duì)于企業(yè)而言，代碼的安全性、服務(wù)的穩(wěn)定性、數(shù)據(jù)是否存在丟失的風(fēng)險(xiǎn)，是會(huì)最被優(yōu)先考量的點(diǎn)。
常用代碼托管工具見(jiàn)下表：
表 1 代碼托管工具對(duì)照表
集成流水線就像傳統(tǒng)的工業(yè)流水線一樣，在經(jīng)歷構(gòu)建、測(cè)試、交付之后，生產(chǎn)出一代一代更新迭代的軟件版本。實(shí)現(xiàn)了軟件產(chǎn)品小步迭代、高頻發(fā)布、適時(shí)集成、穩(wěn)定的系統(tǒng)演進(jìn)線路圖。在選擇集成流水線工具的時(shí)候，我們需要關(guān)注：
版本控制工具的支持；
每個(gè)構(gòu)建是否可以支持指定多個(gè)代碼源 URLS；
是否支持構(gòu)建產(chǎn)物管理庫(kù)，如公有云對(duì)象存儲(chǔ)等；
是否支持部署流水線，類似于一個(gè)或多個(gè)構(gòu)建完成后觸發(fā)另一個(gè)構(gòu)建；
是否支持并行構(gòu)建；
是否支持構(gòu)建網(wǎng)格，以及對(duì)網(wǎng)格內(nèi)機(jī)器管理的能力。如能否將多個(gè)構(gòu)建同時(shí)分配到多個(gè)構(gòu)建機(jī)器上執(zhí)行，以提高執(zhí)行速度；
是否有良好的開放 API，比如觸發(fā)構(gòu)建 API、結(jié)果查詢 API、標(biāo)準(zhǔn)的 Report 接口等；
賬戶體系，是否支持第三方賬戶接入，如企業(yè) LDAP 等；
是否有良好的 Dashboard；
多語(yǔ)言支持；
與構(gòu)建工具（如 Maven，Make，Rake，Nant、Node 等）和測(cè)試工具的集成。
常用集成流水線工具如下表所示：
表 2 持續(xù)集成&持續(xù)部署組件對(duì)照表
服務(wù)發(fā)現(xiàn)為 Deploy 的最后環(huán)節(jié)，缺一不可。無(wú)論是四七層負(fù)載均衡，還是微服務(wù)、RPC 服務(wù)框架，服務(wù)發(fā)現(xiàn)都是產(chǎn)品投產(chǎn)的臨門一腳。服務(wù)注冊(cè)發(fā)現(xiàn)工具選型需要從生態(tài)發(fā)展、便利性、語(yǔ)言無(wú)關(guān)性等角度來(lái)綜合考量。
常用的組件工具如下表：
?
表 3 服務(wù)注冊(cè)組件對(duì)照表
服務(wù)的穩(wěn)定性離不開監(jiān)控系統(tǒng)的保駕護(hù)航。監(jiān)控系統(tǒng)為服務(wù)穩(wěn)定運(yùn)行提供數(shù)據(jù)可視化、異常報(bào)警、異常定位、故障追蹤等能力；同時(shí)監(jiān)控系統(tǒng)還為服務(wù)持續(xù)優(yōu)化升級(jí)提供依據(jù)和考量標(biāo)準(zhǔn)。
監(jiān)控系統(tǒng)有三大基石：指標(biāo)、日志、分布式追蹤。
指標(biāo)體系：聚焦于故障發(fā)現(xiàn)環(huán)節(jié)，服務(wù)以數(shù)字形式評(píng)估出服務(wù) QPS、成功率、延遲、容量等關(guān)鍵指標(biāo)，搭配報(bào)警系統(tǒng)可以保證當(dāng)核心指標(biāo)異常時(shí)及時(shí)通知開發(fā) / 運(yùn)維人員。除了核心指標(biāo)外，服務(wù)還可以將各模塊 / 階段的瓶頸點(diǎn)、外部依賴指標(biāo)量化，建立更加完善服務(wù)狀態(tài)概覽，以便服務(wù)開發(fā) / 運(yùn)維人員快速定位異常，完成根因分析。指標(biāo)系統(tǒng)優(yōu)勢(shì)是聚合能力，用較少的存儲(chǔ)資源和計(jì)算資源表達(dá)系統(tǒng)內(nèi)部狀態(tài)。
常用工具及功能對(duì)照如下：
表 4 指標(biāo)組件對(duì)照表格
日志系統(tǒng)：用于記錄服務(wù)內(nèi)發(fā)生的各類事件。日志系統(tǒng)聚焦故障定位環(huán)節(jié)，與指標(biāo)系統(tǒng)相比，日志系統(tǒng)具有更強(qiáng)的描述性，但也伴隨著更大的存儲(chǔ)空間和計(jì)算存儲(chǔ)資源要求。日志是常用的監(jiān)控方法，比如在具有外部依賴系統(tǒng)的服務(wù)中，一般會(huì)將外部系統(tǒng)發(fā)生的錯(cuò)誤和錯(cuò)誤原因以日志形式記錄下來(lái)，以便在故障定位和復(fù)盤時(shí)恢復(fù)異?，F(xiàn)場(chǎng)環(huán)境。常用方案為 ELK（Elasticsearch、Logstash 和 Kibana ）。
分布式追蹤系統(tǒng)：用于分析服務(wù)調(diào)用關(guān)系。在微服務(wù)盛行的今天，服務(wù)之間調(diào)用關(guān)系越來(lái)越復(fù)雜，微服務(wù)之間相互影響也更加難以定位和排查。分布式追蹤系統(tǒng)聚焦于故障定位環(huán)節(jié)，與指標(biāo)體系和日志體系不同，分布式追蹤系統(tǒng)可以提供服務(wù)之間依賴拓?fù)湫畔ⅲ瑢?duì)于梳理系統(tǒng)調(diào)用拓?fù)?、追蹤下游依賴?dǎo)致的異常意義重大。
常用工具及功能對(duì)照如下：
表 5 分布式追蹤組件對(duì)照表
DevOps 成熟度是評(píng)估效維工具選擇的首要參考維度。不同企業(yè) DevOps 發(fā)展階段不一，為了更好地選擇適配企業(yè)實(shí)際情況的效維工具，我們需要從多維度進(jìn)行評(píng)估：
組織與文化：DevOps 需要文化與組織的變革，包括研發(fā)與運(yùn)維、IT 與業(yè)務(wù)之間的隔閡及部門墻的打破。組織支持 DevOps 的力度，以及現(xiàn)階段文化與 DevOps 的匹配程度是這個(gè)維度的關(guān)鍵。
敏捷開發(fā)：DevOps 是敏捷開發(fā)理念的更科學(xué)的實(shí)踐體系，因此前期敏捷做得好不好直接影響到 DevOps 的效果，兩者是相輔相成的。
CI/CD：CI/CD 不僅僅是工具或流程，更是一種方法論，“持續(xù)"是其核心。CI/CD 管控從代碼提交那一刻到代碼運(yùn)行在生產(chǎn)環(huán)境的整個(gè)過(guò)程。
可視化與自動(dòng)化：可視化是讓 DevOps 人性化的重要一環(huán)，通過(guò)良好的可視化看板，可以快速發(fā)現(xiàn) DevOps 流程中的阻塞點(diǎn)和風(fēng)險(xiǎn)點(diǎn)。自動(dòng)化一方面是為了更快推動(dòng)價(jià)值流從左向右流動(dòng)，另一方面也為了將人為失誤的風(fēng)險(xiǎn)降到最低。
運(yùn)維監(jiān)控與預(yù)警：開發(fā)與運(yùn)維緊密合作，甚至是一個(gè)團(tuán)隊(duì)，對(duì)于運(yùn)維的監(jiān)控和預(yù)警對(duì)所有相關(guān)方可見(jiàn)。
持續(xù)度量與改進(jìn)：DevOps 的效果也是需要度量的，“如果你無(wú)法度量它，你就無(wú)法改進(jìn)它”。DevOps 提倡更頻繁的直面問(wèn)題，度量則是一種很好的方式幫助我們發(fā)現(xiàn)問(wèn)題，并持續(xù)改進(jìn)。
幾乎沒(méi)有嘗試任何 DevOps 實(shí)踐，或只做了一些基礎(chǔ)的 DevOps 工作的企業(yè)，適合選取更低門檻甚至是一站式的工具，功能可以比較單一，但主要注重價(jià)值流的流轉(zhuǎn)效率。而對(duì)于能成熟運(yùn)用各種 DevOps 實(shí)踐的企業(yè)，適合根據(jù)自己的實(shí)際需求選取特定環(huán)節(jié)的組件，并根據(jù)團(tuán)隊(duì)和組織情況進(jìn)行修改或定制。
效維團(tuán)隊(duì)的人員規(guī)模，也會(huì)影響 CI/CD 及監(jiān)控工具鏈的選擇。我們把 20 人以下的效維團(tuán)隊(duì)定義為中小團(tuán)隊(duì)，20 至百人以上定義為大型團(tuán)隊(duì)。正常來(lái)說(shuō)，效維團(tuán)隊(duì)的規(guī)模也同比研發(fā)團(tuán)隊(duì)的規(guī)模。對(duì)于中小團(tuán)隊(duì)來(lái)說(shuō)，選擇學(xué)習(xí)曲線低、能快速搭建且有較完備社區(qū)或官方服務(wù)提供后續(xù)支持的工具為主，容忍功能相對(duì)單一。大型團(tuán)隊(duì)因?yàn)橛休^充足的人力及技術(shù)實(shí)力，有條件選用有一定上手成本，但功能全面且支持深度定制甚至重構(gòu)的工具。
業(yè)務(wù)對(duì)運(yùn)維服務(wù)質(zhì)量的要求，也深度影響效維工具鏈的選擇和搭建。比如金融業(yè)務(wù)，對(duì)穩(wěn)定性和精確性有極高的要求，并且面臨外部強(qiáng)合規(guī)性的監(jiān)管，效維質(zhì)量要求較高。而其它類似推薦的業(yè)務(wù)，即使出現(xiàn)問(wèn)題也只是降低客戶體驗(yàn)，比如展現(xiàn)相關(guān)度不高的商品或新聞，整體并不造成災(zāi)難性的后果，效維質(zhì)量就相對(duì)要求不高。
針對(duì)于效維質(zhì)量要求較高的項(xiàng)目，工具鏈的選擇傾向于功能覆蓋率較全，有大廠背書或業(yè)界口碑，歷史 bug 率不高的工具，整個(gè)的效維流程的時(shí)延以及效率相對(duì)較重。針對(duì)要求較低的項(xiàng)目，工具鏈的選擇傾向于能快速搭建，能覆蓋基本功能的工具鏈條。
企業(yè)的服務(wù)治理標(biāo)準(zhǔn)化程度也會(huì)影響效維工具鏈的選擇。服務(wù)治理標(biāo)準(zhǔn)化包括硬件的標(biāo)準(zhǔn)化、OS 的標(biāo)準(zhǔn)化、語(yǔ)言棧的標(biāo)準(zhǔn)化、通信協(xié)議的標(biāo)準(zhǔn)化、框架的標(biāo)準(zhǔn)化等。標(biāo)準(zhǔn)化程度較高的企業(yè)，效維工具功能可以相對(duì)比較聚焦，不需要覆蓋各層級(jí)多種標(biāo)準(zhǔn)導(dǎo)致的技術(shù)復(fù)雜度。標(biāo)準(zhǔn)化程度較低的企業(yè)，效維工具的體系和結(jié)構(gòu)會(huì)比較龐雜，甚至在有些鏈路環(huán)節(jié)無(wú)法做到完全統(tǒng)一和自動(dòng)化，需要效維人員深度參與修改與定制。
結(jié)合以上的評(píng)估維度，我們認(rèn)為典型的公司型態(tài)包括以下三種：
創(chuàng)業(yè)型企業(yè)一般選擇此種模型，此時(shí)公司以快速迭代服務(wù)、提升開發(fā)效率為第一個(gè)原則，運(yùn)維能力有限。
這種模型推薦使用如下方式搭建 DevOps 工具鏈：
圖 4 建議工具鏈
如上圖所示：
推薦使用 GitLab 代碼管理，GitLab 是企業(yè)級(jí)的開源代碼托管軟件、生態(tài)成熟、穩(wěn)定、社區(qū)龐大、使用簡(jiǎn)單。DevOps 代碼托管流程描述如下：
1.Zadig 完成 CI/CD 流程，提供開發(fā) / 運(yùn)維友好的 Web UI；
2.構(gòu)建服務(wù)鏡像，將鏡像推送到 Harbor，完成鏡像和服務(wù)版本管理；
3.將服務(wù)部署于 Kubernetes，完成服務(wù)升級(jí)。
推薦使用 Kubernetes 服務(wù)部署，Kubernetes 是 Google 開源的服務(wù)部署平臺(tái)，它具有開源、高效、穩(wěn)定、社區(qū)龐大的優(yōu)點(diǎn)。目前 Kubernetes 已經(jīng)成為了云原生的標(biāo)準(zhǔn)服務(wù)部署平臺(tái)，它大大減少了運(yùn)維人員工作負(fù)擔(dān)。在團(tuán)隊(duì)人數(shù)較少時(shí)采用 Kubernetes，不僅節(jié)省人力、服務(wù)部署升級(jí)效率高，還具有強(qiáng)大的系統(tǒng)可擴(kuò)展性。采用 Kubernetes 部署服務(wù)流程描述如下：
1.使用 Kubernetes Deployment，YAML/Helm chart 部署服務(wù)；
2.使用 Kubernetes NodePort Service 進(jìn)行服務(wù)發(fā)現(xiàn)，這種方式簡(jiǎn)單又高效；
3.通過(guò) Nginx 暴露服務(wù)，Nginx 掛載 NodePort Service 后端地址。
4.Kubernetes 可以使用 BridgX 搭建，BridgX 支持管理公有云和私有云計(jì)算資源，基于 BridgX 搭建的運(yùn)維系統(tǒng)可擴(kuò)展性更高；
5.使用公有云計(jì)算資源底座，成本低，運(yùn)維難度低。
推薦使用 CudgX + Grafana 搭建監(jiān)控系統(tǒng)
1.使用 CudgX 建立指標(biāo)體系，CudgX 是源代碼開放的智能診斷平臺(tái)，具有高可用、高性能、服務(wù)負(fù)載評(píng)估、服務(wù)冗余度保持等功能特點(diǎn)，采用 CudgX 存儲(chǔ)核心指標(biāo)為服務(wù)自動(dòng)擴(kuò)縮容提供更高的可擴(kuò)展性，同時(shí) CudgX 兼容 Prometheus 生態(tài)，已有基于 Prometheus 的監(jiān)控系統(tǒng)可以平滑遷移到 CudgX 系統(tǒng)。
2.Grafana 是目前最為流行的監(jiān)控視圖軟件，并提供了簡(jiǎn)單易用的報(bào)警功能，團(tuán)隊(duì)規(guī)模較小時(shí)采用，既不會(huì)浪費(fèi)太多運(yùn)維時(shí)間，又能保證服務(wù)質(zhì)量，還可以保證系統(tǒng)的可擴(kuò)展性。
采用此種監(jiān)控方案總結(jié)如下：
使用 CudgX 業(yè)務(wù)打點(diǎn)，同時(shí)也能使用 Prometheus + CudgX 的組合；
基于 Grafana 搭建視圖和報(bào)警功能。
此模型適合于業(yè)務(wù)穩(wěn)定性要求較高的企業(yè)，此時(shí)企業(yè)一般有穩(wěn)定的服務(wù)和客戶群體，服務(wù)質(zhì)量至關(guān)重要，需要完善的 DevOps 流程保障服務(wù)更新 / 發(fā)布過(guò)程中穩(wěn)定性要求，并滿足提高開發(fā)效率的訴求。
此時(shí)推薦使用如下所示的方式搭建 DevOps 工具鏈：
圖 5 建議工具鏈
如上圖所示：
CI/CD 推薦使用 GitLab ，同時(shí)搭配 Zadig 提供易于用戶操作的 UI。采用此種代碼管理方式流程描述如下：
1.使用 Zadig 持續(xù)集成，Zadig 提供了用戶友好的 WebUI，使用 Sonar 完成代碼檢查，完成單元 /C2C 測(cè)試流程，當(dāng)所有驗(yàn)證通過(guò)后觸發(fā)部署；
2.構(gòu)建服務(wù)鏡像，將鏡像推送到 Harbor，完成鏡像和服務(wù)版本管理；
3.自動(dòng)灰度流量到 SchedulX 。
推薦使用 SchedulX 服務(wù)部署，原因?yàn)?SchedulX 具有完善的金絲雀發(fā)布功能，同時(shí)支持物理機(jī)和容器化部署。對(duì)于服務(wù)質(zhì)量要求較高，代碼發(fā)布、服務(wù)更新應(yīng)該有完善的灰度到全量更新流程，并且當(dāng)核心指標(biāo)異常時(shí)，應(yīng)該阻斷變更，SchedulX 配合 CudgX 可以實(shí)現(xiàn)金絲雀發(fā)布、變更阻斷、動(dòng)態(tài)擴(kuò)縮容等功能，最大程度上保證服務(wù)質(zhì)量。在服務(wù)質(zhì)量要求較高的場(chǎng)景下，部分服務(wù)可能由于網(wǎng)絡(luò)或者資源隔離的原因，希望將服務(wù)部署在獨(dú)立的物理機(jī)中，SchedulX 既支持 Kubernetes 又支持物理機(jī)部署。采用 SchedulX 服務(wù)部署流程描述如下：
1.服務(wù)更新請(qǐng)求提交至 SchedulX；SchedulX 根據(jù)服務(wù)部署類型，將服務(wù)灰度部署于物理機(jī)或者 Kubernetes；
2.SchedulX 監(jiān)控核心指標(biāo)，滾動(dòng)發(fā)布，金絲雀發(fā)布，當(dāng)指標(biāo)異常時(shí)回滾更新操作；
3.按照服務(wù)規(guī)模和復(fù)雜程度不同，用戶可能使用微服務(wù)架構(gòu)，此時(shí)服務(wù)發(fā)現(xiàn)可以基于 Consul ；
4.向外暴露服務(wù)可以通過(guò) Nginx，向內(nèi)暴露服務(wù)可以通過(guò) LVS；
推薦使用 CudgX + Nightingale + ELK + Jaeger + Grafana 搭建監(jiān)控系統(tǒng)?；?CudgX 建立業(yè)務(wù)指標(biāo)體系，具有高可用、高性能、高擴(kuò)展性的特點(diǎn)，同時(shí)搭配 SchedulX 可以完成變更阻斷和服務(wù)自動(dòng)擴(kuò)縮容，大大提供服務(wù)穩(wěn)定性?；?Nightingale 完成基礎(chǔ)指標(biāo)監(jiān)控，可以盡早預(yù)測(cè) / 捕獲宿主機(jī)異常，避免或降低異常影響?；?ELK 完成日志收集，服務(wù)異常時(shí)快速定位故障環(huán)節(jié)，降低故障影響?；?Jaeger 搭建分部署追蹤系統(tǒng)，快速定位系統(tǒng)瓶頸點(diǎn)，定位故障服務(wù)?；?Grafana 搭建監(jiān)控視圖和報(bào)警，為服務(wù)穩(wěn)定性保駕護(hù)航。
基于此方案搭建監(jiān)控系統(tǒng)總結(jié)如下：
使用 CudgX 完成業(yè)務(wù)指標(biāo)打點(diǎn)與指標(biāo)收集，完成業(yè)務(wù)指標(biāo)監(jiān)控；
使用 Nightingale 完成基礎(chǔ)指標(biāo)打點(diǎn)與收集，完成物理機(jī)基礎(chǔ)指標(biāo)（如 CPU/Memory/ 網(wǎng)卡等）監(jiān)控；
使用 ELK 搭建日志系統(tǒng)；
使用 Jaeger 搭建分布式追蹤系統(tǒng)；
使用 Grafana 搭建視圖和報(bào)警系統(tǒng)。
此模型企業(yè)內(nèi)各服務(wù)和組件都趨于成熟，企業(yè)有高穩(wěn)定性要求的核心服務(wù)，有專業(yè)的運(yùn)維團(tuán)隊(duì)，需要完善的 DevOps 平臺(tái)來(lái)保障復(fù)雜的微服務(wù)體系下的服務(wù)質(zhì)量。企業(yè)更關(guān)注于系統(tǒng)平臺(tái)化，將各類組件分門別類組合成為系統(tǒng)平臺(tái)，并搭建 CMDB 管理服務(wù)元數(shù)據(jù)，按組織架構(gòu)管理服務(wù)。
此模型下平臺(tái)化成為主題，各組件有獨(dú)立部門負(fù)責(zé)平臺(tái)支持和運(yùn)維，從微服務(wù)、監(jiān)控平臺(tái)、服務(wù)部署平臺(tái)三個(gè)平臺(tái)角度看，推薦系統(tǒng)架構(gòu)如下所示:
圖 6 建議工具鏈
本文針對(duì)不同 DevOps 成熟度的企業(yè)，量身推薦了持續(xù)集成、持續(xù)部署以及持續(xù)監(jiān)控的工具集合，希望能幫助廣大互聯(lián)網(wǎng)企業(yè)，尤其是中小企業(yè)，快速搭建起自己的效能及運(yùn)維的平臺(tái)，助力企業(yè)快速交付，在日益激烈的行業(yè)競(jìng)爭(zhēng)中收獲技術(shù)紅利。
本文大部分內(nèi)容來(lái)自《星漢未來(lái)綜合運(yùn)維解決方案》白皮書，適合各公司收藏以備技術(shù)選型時(shí)參考，感興趣的可以點(diǎn)擊【閱讀原文】鏈接下載。
作者介紹
田良智，星漢未來(lái)資深技術(shù)專家，曾就職于新浪等公司，擁有十多年運(yùn)維經(jīng)驗(yàn)，參與過(guò)多個(gè)運(yùn)維系統(tǒng)從 0 開始搭建的過(guò)程。
推薦閱讀：
世界的真實(shí)格局分析，地球人類社會(huì)底層運(yùn)行原理
不是你需要中臺(tái)，而是一名合格的架構(gòu)師（附各大廠中臺(tái)建設(shè)PPT）
企業(yè)IT技術(shù)架構(gòu)規(guī)劃方案
論數(shù)字化轉(zhuǎn)型——轉(zhuǎn)什么，如何轉(zhuǎn)？
企業(yè)10大管理流程圖，數(shù)字化轉(zhuǎn)型從業(yè)者必備！
【中臺(tái)實(shí)踐】華為大數(shù)據(jù)中臺(tái)架構(gòu)分享.pdf
華為如何實(shí)施數(shù)字化轉(zhuǎn)型（附PPT）