• DEVOPS是什么
• DEVops概念提出單體架構 瀑布模式分布式架構 敏捷開發(fā)模式微服務架構 DEVOPS
• devops深度理解
• devops實現(xiàn)相關工具devops平臺搭建工具

devops是什么

?

DevOps維基百科定義 DevOps（Development和Operations的組合詞）是一種重視“軟件開發(fā)人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟件交付”和“架構變更”的流程，來使得構建、測試、發(fā)布軟件能夠更加地快捷、頻繁和可靠。

?

這里先給出維基百科的定義，沒指望你一下子看懂，先有個概念了解一下。

devops概念提出

單體架構 瀑布模式

單體應用架構

瀑布開發(fā)模式

以電商系統(tǒng)為例，單體應用架構為 LNMP，這個時候只有 DEV 沒有 OPS，DEV 就是全棧，就跟我們上大學玩的 demo 一樣，項目開發(fā)好，找臺服務器安裝好環(huán)境，把 jar 包 scp 到遠程服務器，放上去開啟服務就可以。

這個時候服務監(jiān)控也簡單，服務出了問題，直接去線上看一下運行日志，為了解放雙手監(jiān)控服務，開發(fā)者會寫一些腳本分析日志，服務器少，部署簡單，通常開發(fā)就可以完成運維的工作，不需要專門的運維來做部署，所以開發(fā)模式很簡答，直接按照瀑布流方式開發(fā)就可。

分布式架構 敏捷開發(fā)模式

分布式架構

敏捷開發(fā)模式

隨著業(yè)務體量發(fā)展越來越大，一臺機器扛不住，那么就加機器，單機變多機，業(yè)務架構也開始加入了 nginx,cdn,緩存等通用基礎服務，業(yè)務變多肯定會招人，就涉及到多人協(xié)同開發(fā)，多人多機器模式。

多人協(xié)同開發(fā)問題:

先說說多人協(xié)同開發(fā)問題，人員一多，為了更好的分工，大多會將項目進行拆分，每個人負責專注于一部分，有點包干到戶的感覺，敏捷開發(fā)的核心理念就是既然我們無法充分了解用戶的真實需求是怎樣的，將一個大的目標不斷拆解，把它變成一個個可交付的小目標，然后通過不斷迭代，以小步快跑的方式持續(xù)開發(fā)。。另外，一個項目是很大的，為了保證項目質量，測試環(huán)節(jié)不可減少，為了加快速度增大開發(fā)效率，QA的工作最好是和開發(fā)同步交替進行的，需要將測試環(huán)節(jié)從后面注入到整個開發(fā)環(huán)節(jié)當中，每次可交付的都是一個可用的功能集合，對開發(fā)交付的內容進行持續(xù)驗證。這樣開發(fā)產(chǎn)品的可控性也更強，遇到了sb甲方的時候，階段性的讓他檢驗一下項目成果，防止畫雞成鴨。

打架嗎？

多機器問題:

再說說多機器問題，之前機器很少架構簡單的時候，開發(fā)就可以干運維的活，就算加了幾臺服務器，那也是腳本將 JAR 包同時發(fā)布到這些機器上，好像也挺簡單，但是會有兩個人同時上線部署被覆蓋的問題，所以大家在上線之前可能會去群里吆喝一聲，”我要上線了，大家先別上線哈“，可想而知這樣效率也很低下。

公司業(yè)務一大，像大公司的動不動就是幾千臺服務器，就需要專門的運維介入了，一方面是因為開發(fā)分工每個人都專注于自己的事情，不會那么用心進行維護，另一方面是運維的學習成本確實變高了，開發(fā)人質量參差不齊，服務器要是每個人都可以上估計領導每天晚上都要做噩夢。但是這個時候也不是 DEVOPS，而是 DEV OPS，這時 Ops 的主要職責就是：硬件維護、網(wǎng)絡設備維護、DBA 、基礎服務維護、數(shù)據(jù)監(jiān)控等，運維們擅長寫各種部署，監(jiān)控腳本，減少機械的重復工作，開發(fā)模式變成了敏捷開發(fā)模式。

開發(fā)和運維角色的天生對立問題：

加入運維，就要協(xié)調人員配合，運維的宿命就是維穩(wěn)，他們是很討厭變動的；開發(fā)的天職確是不斷地推代碼上線，進行代碼變動，更替迭代，這兩個工種天生就是對立的。

很多大公司有那種，開發(fā)人員想要上線，需要提交各種審批，層層簽字畫押，多少人的上線激情被一句冷冰冰的‘還沒到窗口發(fā)布期’給潑的透心涼。所以，敏捷開發(fā)解決了協(xié)同開發(fā)和多機器部署開發(fā)問題，但是沒有解決內部人員的矛盾，留著這個矛盾在公司，開發(fā)和運維隨時都可能約‘生死架’。

微服務架構 DEVOPS

微服務架構

DEVOPS

?

wiki定義微服務: 微服務（英語：Microservices）是一種軟件架構風格，它是以專注于單一責任與功能的小型功能區(qū)塊 (Small Building Blocks) 為基礎，利用模塊化的方式組合出復雜的大型應用程序，各功能區(qū)塊使用與語言無關 (Language-Independent/Language agnostic）的API集相互通信。

?

上面是我摘自wiki對微服務的定義，注意幾個關鍵詞：軟件架構風格，小型功能區(qū)塊，模塊化，語言無關。

第一，公司發(fā)展到BAT這種體量，會招很多人，JAVA，PHP，GO 技術棧都會有，需要協(xié)調技術棧；第二，項目到后期往往會變得很大，全部都兌到一個項目里，最直接的后果就是項目變得很大，上線項目啟動時間變長，一個BUG可能導致整個業(yè)務全線崩潰，最終的后果就是項目變得越來越難以維護，加一個改一個東西幾乎搞不動，而且還越來越難重構，牽一發(fā)而動全身。

所以，拆分解耦是最終的出路，將項目拆成一個個小的服務單獨部署，以電商項目為例如圖，將整個項目拆分為用戶服務，商品服務，訂單服務，積分服務……每個服務單獨部署，之間通過互相調用的方式來交互，而且可以將一些基礎服務例如上傳圖片，發(fā)送短信等很多服務都需要的基礎東西，抽象到一個單獨的服務，也就是前些年鼓吹的很厲害的‘中臺服務’。

拆分部署催生出DEVOPS 再看看這種架構下的開發(fā)模式DEVOPS，運維需要做的上線工作，主要就是將代碼部署到對應的機器里面，微服務有那么多的服務，每個大點的公司幾百個服務不算多，而且還可能隨時搞一個服務出來，如果還按照原始的腳本部署方式，可能最后連是哪個腳本都找不到。而且，如果每個服務上線都需要運維來同意，開發(fā)也太卑微了，估計要天天求著運維同意發(fā)布，運維也會煩不勝煩。

那么為何不能再遠程部署一些機器，專門用來管理代碼，進行上線工作，由運維事先把上線的規(guī)則都給定義好了，開發(fā)只要按照他的規(guī)則都訪問這臺服務器進行各自的代碼合成和發(fā)布，自己上線呢，能用代碼自動完成的事情就絕不要手動解決，這是每個開發(fā)人員都在想的東西。運維需要做的事情，慢慢的都沉淀到了各個平臺上面，例如監(jiān)控，有專門的監(jiān)控組件和可視化，基礎服務例如服務器，CDN，負載均衡等基礎服務可以外包到云服務廠商，日志也有專門的日志工具，鏈路追蹤也有專門的組件和可視化，還有網(wǎng)關等，漸漸的，只要這些都配置好了，開發(fā)也可以做運維的部分工作，畢竟開發(fā)才是最了解代碼的人，哪里出了問題看看監(jiān)控日志，可以最快速度定位到問題，于是DEVOPS開發(fā)模式誕生了，開發(fā)也是運維。

devops深度理解

我們知道，一個軟件從零開始到最終交付，大概包括以下幾個階段：產(chǎn)品規(guī)劃、開發(fā)編碼、構建、QA測試、發(fā)布、部署和維護。

最初大家說到DEVOPS，都是指的‘開發(fā)運維一體化’，如下圖:

現(xiàn)在大家說的 DevOps 已經(jīng)是擴大到“端到端”的概念了，如下圖：

廣義上的DevOps

DevOps 的三大支柱之中，即人（People）、流程（Process）和平臺（Platform）。即

DevOps = 人 流程 平臺

人 流程 = 文化

流程 平臺 = 工具

平臺 人 = 賦能

devops實現(xiàn)相關工具

人自然不用多說，開發(fā)前后中涉及到的所有人，流程前期是產(chǎn)品出原型，UI出設計，然后前后端代碼開發(fā)，QA測試，最終部署上線，下圖是部分流程圖：

流程圖

這里重點來看看devops平臺搭建工具，工具很多，組件很多，百家爭鳴,這里我列舉的大多數(shù)是我公司用的，也是大部分公司都在用的。

devops平臺搭建工具

項目管理（PM）：jira。運營可以上去提問題，可以看到各個問題的完整的工作流，待解決未解決等；

代碼管理：gitlab。jenkins或者K8S都可以集成gitlab，進行代碼管理，上線，回滾等；

持續(xù)集成CI（Continuous Integration）：gitlab ci。開發(fā)人員提交了新代碼之后，立刻進行構建、（單元）測試。根據(jù)測試結果，我們可以確定新代碼和原有代碼能否正確地集成在一起。

持續(xù)交付CD（Continuous Delivery）：gitlab cd。完成單元測試后，可以把代碼部署到連接數(shù)據(jù)庫的 Staging 環(huán)境中更多的測試。如果代碼沒有問題，可以繼續(xù)手動部署到生產(chǎn)環(huán)境中。

鏡像倉庫：VMware Harbor，私服nexus。

容器：Docker。

編排：K8S。

服務治理：Consul。

腳本語言：Python。

日志管理：Cat Sentry，還有種常用的是ELK。

系統(tǒng)監(jiān)控：Prometheus。

負載均衡：Nginx。

網(wǎng)關：Kong，zuul。

鏈路追蹤：Zipkin。

產(chǎn)品和UI圖：藍湖。

公司內部文檔：Confluence。

報警：推送到工作群。

有了這一套完整的流程工具，整個開發(fā)流程涉及到人員都可以無阻礙的進行協(xié)調工作了，開發(fā)每天到公司，先看看jira,看看線上日志，出了問題看看監(jiān)控日志，運營同學反饋問題不著急的去JIRA，著急的群里吆喝，產(chǎn)品和UI的圖直接藍湖看，運維關注監(jiān)控著大盤，改革春風開滿地，互聯(lián)網(wǎng)人民真高興~

這一篇有點姍姍來遲的意味，之前一直陷入了迷茫不知道該寫什么，于是低調的修煉，有了這一篇，有問題歡迎指正，關注我的公眾號’阿甘的碼路‘，即可聯(lián)系到我，很開心你能看到這里，共同努力，共同進步。