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