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

devops是什么

?

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

?

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

devops概念提出

單體架構(gòu) 瀑布模式

單體應(yīng)用架構(gòu)

瀑布開發(fā)模式

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

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

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

分布式架構(gòu)

敏捷開發(fā)模式

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

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

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

打架嗎？

多機(jī)器問題:

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

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

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

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

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

微服務(wù)架構(gòu) DEVOPS

微服務(wù)架構(gòu)

DEVOPS

?

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

?

上面是我摘自wiki對微服務(wù)的定義，注意幾個(gè)關(guān)鍵詞：軟件架構(gòu)風(fēng)格，小型功能區(qū)塊，模塊化，語言無關(guān)。

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

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

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

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

devops深度理解

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

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

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

廣義上的DevOps

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

DevOps = 人 流程 平臺(tái)

人 流程 = 文化

流程 平臺(tái) = 工具

平臺(tái) 人 = 賦能

devops實(shí)現(xiàn)相關(guān)工具

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

流程圖

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

devops平臺(tái)搭建工具

項(xiàng)目管理（PM）：jira。運(yùn)營可以上去提問題，可以看到各個(gè)問題的完整的工作流，待解決未解決等；

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

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

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

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

容器：Docker。

編排：K8S。

服務(wù)治理：Consul。

腳本語言：Python。

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

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

負(fù)載均衡：Nginx。

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

鏈路追蹤：Zipkin。

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

公司內(nèi)部文檔：Confluence。

報(bào)警：推送到工作群。

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

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