1.?前言
對于搞云原生應(yīng)用的同學(xué)，對于DevOps和DORA應(yīng)該都不陌生。但對于傳統(tǒng)應(yīng)用程序開發(fā)的同學(xué)，經(jīng)常被DevOps, Microservice, CICD, DORA這些新穎的名詞搞得暈頭轉(zhuǎn)向。那么到底什么是DevOps? 什么是DORA呢？
2. 解析
2.1 DevOps
DevOps并不是憑空創(chuàng)造出來的一個概念，它也是有著歷史的發(fā)展過程的。在知乎上找到了一篇不錯的文章，對DevOps的解析很清楚，感興趣的同學(xué)可以去讀一下DevOps到底是什么意思？ - 知乎 (zhihu.com)。
簡而言之，DevOps是繼軟件開發(fā)的瀑布模型、敏捷模型后的第三種軟件開發(fā)的方法論，可以理解為：
- 第一階段：瀑布模型
- 第二階段：敏捷模型
- 第三階段：DevOps
在瀑布模型中，大家分工合作，開發(fā)、測試、部署、運維，每一部分都有專門的團隊負責(zé)，開發(fā)完成后進入測試環(huán)節(jié)，測試完成后進去部署環(huán)節(jié)，部署完成后進入運維環(huán)節(jié)，每個環(huán)節(jié)都是獨立的，有著獨立的開發(fā)團隊、測試團隊、部署團隊、運維團隊。
瀑布模型的弱點在于，軟件上線周期長，對于新需求的反映速度慢。因而，在瀑布模型的基礎(chǔ)上，衍生出了敏捷開發(fā)，強調(diào)“開發(fā)測試”一起搞，小步快走完成開發(fā)任務(wù)，但仍然有獨立的部署團隊和運維團隊。
DevOps是敏捷模型的進一步升級，為了進一步加快軟件的上線速度，更快地對客戶需求做出反應(yīng)，強調(diào)“開發(fā)測試部署運維”全部一起搞定。
這也就是DevOps縮寫的含義，也即Development and Operation, 開發(fā)和運維。
總結(jié)起來，采用DevOps這種方法論，主要就是想在軟件開發(fā)過程中提升以下幾點：
- 更專注于用戶的需求
- 更快的上線速度
- 更自動化流程
- 更穩(wěn)定的運行時長
為了實現(xiàn)這一目標，有著一些列輔助DevOps的工具和方法論，例如包括軟件架構(gòu)上的微服務(wù)設(shè)計Microservices、云原生的部署方案K8S、持續(xù)集成持續(xù)交付CICD等。
2.2 設(shè)計上的妥協(xié)與變通
通過上面的介紹可以了解到，實施DevOps，不僅僅要在軟件開發(fā)理念上改變，也要在組織架構(gòu)上發(fā)生改變，要打破開發(fā)測試部署運維的組織邊界和職能邊界，同時為了完成這一目標，軟件的架構(gòu)設(shè)計也會發(fā)生變動，即從之前的“單體架構(gòu)monolithic architecture”轉(zhuǎn)變成“微服務(wù)架構(gòu)Microservices”。
云原生為什么要使用微服務(wù)架構(gòu)，讓我們首先對比下兩種架構(gòu)的優(yōu)勢與劣勢。
對于傳統(tǒng)的單體架構(gòu)：
| 優(yōu)勢 | 劣勢 | |
| 1 | 易開發(fā)（同一個代碼庫，更容易開發(fā)） | 開發(fā)速度慢（大型的用程序使開發(fā)更復(fù)雜、更慢） |
| 2 | 高性能（集中式的代碼庫和數(shù)據(jù)庫，一個API通?？梢詧?zhí)行許多API在微服務(wù)中執(zhí)行的相同功能） | 可擴展性差（不能擴展單個組件） |
| 3 | 測試簡單 （端到端測試可以比分布式應(yīng)用程序更快地執(zhí)行） | 可靠性弱（任何模塊出現(xiàn)錯誤，都可能影響整個應(yīng)用程序的可用性） |
| 4 | 易調(diào)試 （所有代碼都放在一個地方，跟蹤請求和發(fā)現(xiàn)問題容易） | 新技術(shù)應(yīng)用障礙（框架或語言的更改都會影響整個應(yīng)用程序，使得更改通常既昂貴又耗時） |
| 5 | 靈活性差（受到單體中已經(jīng)使用的技術(shù)的限制） | |
| 6 | 部署代價大（一個小更改需要重新部署整個單體） |
對于微服務(wù)架構(gòu)：
| 優(yōu)勢 | 劣勢 | |
| 1 | 敏捷的部署與擴展（彈性擴展、獨立部署） | 開發(fā)蔓延（微服務(wù)增加了更多的復(fù)雜性、更多冗余重復(fù)的API，如果管理不當，就會導(dǎo)致開發(fā)速度變慢，操作性能變差） |
| 2 | 高可維護性和可測試性（易隔離和修復(fù)單個服務(wù)中的錯誤和錯誤） | 指數(shù)級的基礎(chǔ)設(shè)施成本（每個新的微服務(wù)在測試套件、部署腳本、托管基礎(chǔ)設(shè)施、監(jiān)控工具等方面都有自己的成本） |
| 3 | 更靈活的技術(shù)（不同的服務(wù)可以通過不同的技術(shù)棧完成） | 增加了管理成本（團隊需要增加另一個層次的溝通和協(xié)作，以協(xié)調(diào)更新和接口） |
| 4 | 高可靠性（可更改特定服務(wù)部署，而不會危及整個應(yīng)用程序） |
調(diào)試復(fù)雜（每個微服務(wù)都有自己的日志集，這使得調(diào)試變得更加復(fù)雜。另外，單個業(yè)務(wù)流程可以跨多臺服務(wù)器運行，這進一步增加了調(diào)試的復(fù)雜性） |
| 5 | 缺乏標準化（如果沒有一個通用的平臺，語言、日志標準和監(jiān)控標準，管理會失控） |
可見，微服務(wù)架構(gòu)雖然靈活，但微服務(wù)也不是萬靈丹，微服務(wù)架構(gòu)帶來系統(tǒng)敏捷性的同時，也有著很多的妥協(xié)和挑戰(zhàn)。例如為了微服務(wù)間的解耦，可能需要創(chuàng)建更多冗余的服務(wù)或數(shù)據(jù)，這與之前軟件設(shè)計中的do not repeat yourself是完全相反的思路，這種設(shè)計也為數(shù)據(jù)的最終一致性帶來了不小挑戰(zhàn)。
可以說，實施DevOps方法論和微服務(wù)架構(gòu)目前也仍然是在不斷試錯、不斷摸索的過程中。
有一點需要注意的是，使用微服務(wù)架構(gòu)，構(gòu)建云原生應(yīng)用程序的初衷并非是“降低運營成本”，因為隨著微服務(wù)數(shù)量的增加，其所消耗的基礎(chǔ)設(shè)施成本也是指數(shù)級增長的。使用微服務(wù)架構(gòu)的初衷是獲得更高的敏捷性，獲得更快的部署速度，更快的軟件迭代周期。
2.3 DORA
DORA是DevOps Research & Assessment的縮寫，它是研究如何評判DevOps運行狀況的一個組織 DORA | DevOps Quick Check。總結(jié)下來，這個組織提出了5點衡量標準:
- （速度）Deployment Frequency: 部署的頻率
- （速度）Lead time for changes: 從代碼提交，到在生產(chǎn)系統(tǒng)上生效的時間
- （穩(wěn)定性）Time to restore service: 部署之后，出了問題，需要多久能修復(fù)
- （穩(wěn)定性）Change Failure Rate: 由于部署產(chǎn)生問題的百分比
- （運維角度）Reliability：服務(wù)是不是穩(wěn)定的 ---> （這一條是新提出的）
這5點標準可以量化成具體的衡量指標，用于衡量一個實施DevOps方法論的組織的運行狀況。例如下圖給出的一個參考標準：
?總的來說，通過DORA提出的指標，我們可以從部署的速度和服務(wù)的穩(wěn)定性兩個角度，去量化軟件開發(fā)團隊運行的狀況。
所以說，DORA的核心其實是提出了DevOps的“可量化的衡量指標” 。
3. 總結(jié)
本文簡單總結(jié)和介紹了DevOps和DORA的基礎(chǔ)概念，對于云原生開發(fā)的很多衍生工具和概念沒有過多的介紹，包括例如Zero-Downtime Deployment，Zero-Downtime DB Migration，Resilience，F(xiàn)eature Toggles，Monitoring & Alerting， Product Metrics等等，這些概念的核心都是圍繞著DevOps方法論的思想所服務(wù)的。文章來源：http://www.zghlxwxcb.cn/news/detail-516436.html
首先把握DevOps的初衷和Miscrosevices架構(gòu)的特點，是學(xué)習(xí)其它相關(guān)概念的前提，希望本文對你了解DevOps有所幫助。文章來源地址http://www.zghlxwxcb.cn/news/detail-516436.html
到了這里，關(guān)于什么是DevOps？ 什么是DORA？的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
