CODING DevOps 系列第三課：雲計算、雲原生模式下 DevOps 的建設

本文首先會和你們分享當前整個應用生命週期的演變歷程，而後講解雲計算模式下 DevOps 建設包含的過程、流程規範和標準，最後講解雲原生時代到來會帶來哪些改變，以及標準化的建設會有哪些改變和突破。

應用的演變歷程

企業數字化轉型過程和雲的迭代發展是相互做用的。在 2007 年以前主要用物理機來做爲咱們當前應用的載體。而在 2007 年，KVM 誕生，它能讓底層操做系統和一些虛擬的網絡設備作一些虛擬化的輸出。2007 年 - 2010 年是虛擬化發展較好的週期，VMware 和 openstack 是當時的表明生態。到了 2013 年 Docker 開服，雲計算迎來了蓬勃發展的週期。2014 年，企業的部分業務開始逐步遷移雲上。2017 年後到今天爲止，在雲原生的模式下，開發人員或者整個 it 部門更聚焦在業務的發展上，全部咱們不關心的部分能夠所有由雲來管理。雲開發沒必要關心開發在哪裏，雲服務不關心調用到哪裏，而云資源方面也不用關心運行到了哪裏。這就是從基礎設施上雲到業務上雲，再到當前的全棧雲，這樣的一條全企業數字化轉型之路。

在物理機階段，使用的是單體架構，這樣的架構系統封閉、沒法複用，且高度耦合，內部交互複雜。而在第二階段，採用了面向服務的 SOA 架構，這種架構一般須要 ESB 進行系統集成，進行應用模塊解耦，須要統一部署。可是這種架構一般須要較大規模的團隊，且可能存在職責割裂。第三階段是當前使用的比較多的微服務架構，它能充分利用 DevOps，徹底解耦能充分利用雲化資源自動彈性伸縮等特性，支持高可用，能升級、擴容但不中斷業務。

這張圖片能較好的展現應用的生命週期管理，以應用爲中心，在應用之上是基礎資源管理層面，這個層面能夠管理應用對應的資產、環境、資源、流水線、部署和監控，這是以基礎資源爲核心思想下 DevOps 的建設方向。隨着愈來愈雲化和微服務化，咱們關注的視角從基礎資源逐步轉成服務思想。

雲計算模式下的 DevOps

在物理機時代，隨着業務的發展，可能會出現基礎設施增加，軟件複雜度提高，流量衝擊和更新頻率變高這些問題。基礎設施增加和軟件複雜程度提高會給運維帶來壓力，流量衝擊要求運維的測試要有多樣的變化，更高的更新頻率要求研發人員的快速反饋以及更靈活的需求變動。

在這樣的狀況下，DevOps 建設迫在眉睫，企業須要提高應用交付的效率和質量，須要愈來愈多樣化的應用部署方式。DevOps 建設要首先要作的是敏捷的建設，所以須要更靈活的需求管理工具，在整個應用交付階段須要自動化構建和環境快速管理。而後在測試的階段，咱們須要作自動化測試，才能在流程中管控好質量，另外還須要有一個統一的製品管理。從軟件開發到應用交付之間，須要有一套統一的製品庫將全部的製品進行統一納管，基於統一的製品能夠進行智能化的驗收測試。在這整個階段，核心準則是版本控制一切，內建質量、自動化，過程度量。

這個圖片是端到端的 DevOps 能力圖譜，建設的重點在圖譜下方的持續交付工具鏈。咱們須要採起統一的代碼管理工具，幫助咱們自動化的提高代碼的質量。在安全方面，咱們也會運用安全掃描工具集成到流程中，讓它進行自動編譯。另外，在持續部署階段，要作好數據庫的發佈，對不一樣版本的接口作好管理，並結合一些好的自動化的工具作自動化測試。這些功能點須要一個交付部署流水線串連起來。

咱們能夠看到，在端到端的能力中會有不少步驟，也須要很是多的工具去執行，如何將這些工具進行很好的串連呢？在企業生產過程當中，核心目標有三項：效率、質量和成本，所以能夠沿用製造業的流水線來幫助咱們快速的生產軟件。流水線中咱們須要關注 4 項指標：發佈頻率、變動時長、服務恢復時長和變動失敗率。

雲原生帶來的改變

雲原生是一個複雜的東西，它包含開發過程、應用依賴、編排管理、流程管理、數據分析以及很是多的組件。在雲計算的模式下，咱們能夠作到快速交付應用、成果快速發佈，可是咱們交付的產品是否能給業務帶來增加，知足客戶的須要呢？這就涉及到如何將應用交付轉變爲價值交付。經過可靠、可重複的流水線，快速進行軟件生產，提高應用效率和軟件交付效率，這就是應用交付。而價值交付是指可以快速地響應市場變化，在客戶需求不肯定的狀況下，生產出客戶滿意的軟件。

如何實現價值交付？要基於可靠可重複的流水線，簡歷自動化的應用交付體系。將敏捷過程全面融入到 DevOps 體系中。架構全面微服務轉型，基礎設施雲化，讓開發專一於業務開發。將運營歸入到 DevOps 範疇，實現數字化運營。

點擊觀看課程完整視頻。