這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)碛嘘P(guān)如何看待DevOps，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

成都地區(qū)優(yōu)秀IDC服務(wù)器托管提供商(創(chuàng)新互聯(lián)).為客戶提供專業(yè)的德陽(yáng)服務(wù)器托管,四川各地服務(wù)器托管,德陽(yáng)服務(wù)器托管、多線服務(wù)器托管.托管咨詢專線：13518219792

DevOps究竟是什么

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

DevOps是一種文化轉(zhuǎn)變，或者說是一個(gè)鼓勵(lì)更好地交流和協(xié)作（即團(tuán)隊(duì)合作）以便于更快地構(gòu)建可靠性更高、質(zhì)量更好的軟件的運(yùn)動(dòng)。——Mike Kavis

Mike Kavis是美國(guó)Cloud Technology Partners公司的副總裁兼首席架構(gòu)師，他也更加詳細(xì)地描述介紹說：DevOps是軟件開發(fā)生命周期（SDLC）從瀑布式到敏捷再到精益的發(fā)展。DevOps超越了敏捷，它的關(guān)注點(diǎn)是從SDLC中移除浪費(fèi)。通常情況下，發(fā)現(xiàn)浪費(fèi)或者瓶頸的形式包括：不一致的環(huán)境，人工的構(gòu)建和部署流程，差的質(zhì)量和測(cè)試實(shí)踐，IT部門之間缺少溝通和理解，頻繁的中斷和失敗的協(xié)定以及那些需要珍貴的資源、花費(fèi)重要的時(shí)間和金錢才能保持系統(tǒng)運(yùn)行的全套問題。

他還看到另一個(gè)重復(fù)浪費(fèi)是：一個(gè)DevOps團(tuán)隊(duì)的第一步通常是決定他們是否應(yīng)該使用Chef或者Puppet（或者是Salt、Ansible等其他任何熱門的東西）。他們甚至還沒有定義自己打算解決的問題，即使他們手頭的工具可以解決它們。這些團(tuán)隊(duì)通常會(huì)緊張地構(gòu)建數(shù)千行腳本，但是這就產(chǎn)生了一個(gè)問題：“我們的職責(zé)是編寫Chef腳本還是通過質(zhì)量更好、更穩(wěn)定的產(chǎn)品更快地進(jìn)入市場(chǎng)？”。在大多數(shù)情況下，這些團(tuán)隊(duì)會(huì)將自己逼入絕境，大量的專有腳本實(shí)際上是增加了系統(tǒng)的浪費(fèi)，而隱藏在DevOps運(yùn)動(dòng)之后的驅(qū)動(dòng)力是從系統(tǒng)中移除浪費(fèi)，這些團(tuán)隊(duì)并沒有做到這一點(diǎn)。Mike Kavis原文

而目前對(duì) DevOps 有太多的說法和定義，不過它們都有一個(gè)共同的思想：“解決開發(fā)者與運(yùn)維者之間曾經(jīng)不可逾越的鴻溝，增強(qiáng)開發(fā)者與運(yùn)維者之間的溝通和交流”。而我個(gè)人認(rèn)為，DevOps 可以用一個(gè)公式表達(dá)：

文化觀念的改變 + 自動(dòng)化工具 = 不斷適應(yīng)快速變化的市場(chǎng)

其核心價(jià)值在于以下兩點(diǎn)：

1. 更快速地交付, 響應(yīng)市場(chǎng)的變化。

2. 更多地關(guān)注業(yè)務(wù)的改進(jìn)與提升。

當(dāng)理解了什么是DevOps后，那我們?yōu)槭裁葱枰?？它給我們又帶來了哪些好處？

為什么需要DevOps

當(dāng)今世界改變的速度已與過去不同，而每當(dāng)經(jīng)歷一個(gè)顛覆性的技術(shù)革命時(shí)，都給這個(gè)世界帶來了深刻的變化，大數(shù)據(jù)、云計(jì)算、人工智能、VR/AR和區(qū)塊鏈等新興技術(shù)推動(dòng)著世界不斷變化，如何應(yīng)對(duì)這樣一個(gè)VUCA時(shí)代，讓我們能夠在環(huán)境變化的時(shí)候快速響應(yīng)呢？

V=Volatillity（易變性）是變化的本質(zhì)和動(dòng)力，也是由變化驅(qū)使和催化產(chǎn)生的

U=Uncertainty（不確定性）缺少預(yù)見性,缺乏對(duì)意外的預(yù)期和對(duì)事情的理解和意識(shí)

C=Complexity（復(fù)雜性）企業(yè)為各種力量，各種因素，各種事情所困擾。

A=Ambiguity（模糊性）對(duì)現(xiàn)實(shí)的模糊，是誤解的根源，各種條件和因果關(guān)系的混雜。

接下來我將從“產(chǎn)品迭代”和“技術(shù)革新”兩個(gè)層面分析介紹如何變化的。

產(chǎn)品迭代

我們不管是做互聯(lián)網(wǎng)還是做游戲，其實(shí)最終都是在做產(chǎn)品，做一款用戶喜歡的產(chǎn)品。喬布斯有句非常著名的名言：“消費(fèi)者并不知道自己需要什么，直到我們拿出自己的產(chǎn)品，他們才發(fā)現(xiàn)，這是我想要的東西”。所以喬幫主能夠在一開始的時(shí)候就設(shè)計(jì)好了產(chǎn)品最終的效果，然后按照零部件一步步迭代生產(chǎn)，其步驟可以用下圖所示：

全世界只有一個(gè)喬布斯，而在我們現(xiàn)實(shí)的產(chǎn)品迭代中卻是這樣的，對(duì)話如下：

用戶：我平時(shí)上下班都是走路，每天都要走五公里，好辛苦，有沒有辦法幫我設(shè)計(jì)個(gè)工具，解決下我的痛點(diǎn)。

我們思考了下，覺得這個(gè)不是很難嘛，可以試下，于是我們討論 -> 設(shè)計(jì) -> 開發(fā) -> 測(cè)試 -> 交付給用戶了一個(gè)滑板。

用戶：這個(gè)滑板不好操控，可以給我加個(gè)扶手嗎？

然后我們按照用戶新的需求，生產(chǎn)了個(gè)滑板車。

用戶：滑板車得滑著走，能不能讓我可以騎著走的。

我們繼續(xù)改進(jìn)產(chǎn)品，生產(chǎn)了個(gè)自行車。

用戶：自行車還得登著走，路程遠(yuǎn)了也很累。

我們又繼續(xù)優(yōu)化，把它變成了電瓶車。

用戶：電瓶車倒是解決了的需求，不過就是不太安全，能再優(yōu)化下產(chǎn)品嗎？

經(jīng)過各種努力我們最后生產(chǎn)出了一輛漂亮的小轎車交付給了用戶，終于讓用戶滿意了。

現(xiàn)實(shí)中的用戶其實(shí)一開始并不知道自己想要什么，但是直到看到了我們的產(chǎn)品，他才知道自己不想要什么。

即讓現(xiàn)實(shí)的產(chǎn)品迭代是如此曲折和反復(fù)的，那我們有沒有辦法快速交付價(jià)值、靈活響應(yīng)變化呢？答案就是DevOps，它是面向業(yè)務(wù)目標(biāo)，助力業(yè)務(wù)成功的最佳實(shí)踐。

產(chǎn)品的迭代需要DevOps，那么技術(shù)的革新更加促進(jìn)了DevOps的快速發(fā)展和落地實(shí)施，下面讓我們一起看一下技術(shù)又是如何支持產(chǎn)品的迭代而不斷革新地呢？

技術(shù)革新

在以前的系統(tǒng)中業(yè)務(wù)單一、邏輯簡(jiǎn)單、用戶量少，項(xiàng)目團(tuán)隊(duì)的規(guī)模一般在 10~30人。而現(xiàn)在的系統(tǒng)要面對(duì)不同用戶的定制化推薦等，互聯(lián)網(wǎng)連接著人與人、人與物、以及物與物，業(yè)務(wù)也變得越來越復(fù)雜，功能越來越多，如果整個(gè)系統(tǒng)耦合在一起，則必定會(huì)牽一發(fā)而動(dòng)全身，導(dǎo)致系統(tǒng)維護(hù)起來相當(dāng)困難。

因此IT技術(shù)架構(gòu)也隨著系統(tǒng)的復(fù)雜化而不斷地變化革新，從早期所有服務(wù)的All In One發(fā)展到現(xiàn)在的微服務(wù)架構(gòu)、從純手動(dòng)操作到全自動(dòng)化流程、從單臺(tái)物理機(jī)到云平臺(tái)，下圖展示了IT技術(shù)革新的變化：

現(xiàn)在DevOps已經(jīng)成為發(fā)展的趨勢(shì)了，那它又是怎么實(shí)現(xiàn)落地的呢？

如何實(shí)現(xiàn)DevOps的落地

知之真切篤實(shí)處即是行，行之明覺精察處即是知 —— 明?王守仁《傳習(xí)錄》

在些我引用了圣賢王陽(yáng)明的一句名言，他提倡“知行合一”，通俗的講就是做事情要理論與實(shí)踐相結(jié)合。我們?cè)趯?shí)現(xiàn)DevOps落地時(shí)也一定要遵循“理論與實(shí)踐相結(jié)合”的方式進(jìn)行，理論就是我們做事的指導(dǎo)思想，而實(shí)踐就是具體做事的方法，接下來我就從我在公司中是如何按照理論與實(shí)踐相結(jié)合來推動(dòng)DevOps落實(shí)地。

落實(shí)DevOps的指導(dǎo)思想

首先我們還是要回到什么是DevOps，如果大家忘記了可以回到之前再溫故一下，包括我總結(jié)的DevOps公式。

其實(shí)DevOps核心思想就是：“快速交付價(jià)值，靈活響應(yīng)變化”。其基本原則如下：

• 高效的協(xié)作和溝通；

• 自動(dòng)化流程和工具；

• 快速敏捷的開發(fā)；

• 持續(xù)交付和部署；

• 不斷學(xué)習(xí)和創(chuàng)新。

然而這些基本原則又是如何與項(xiàng)目研發(fā)息息相關(guān)的呢，也就是它們?cè)谖覀兊拈_發(fā)過程中的各個(gè)環(huán)節(jié)是如何體現(xiàn)的？請(qǐng)看下面一張來自《success with enterprise dev-ops - whitepaper》的介紹圖：

• 敏捷管理：一支訓(xùn)練有素的敏捷開發(fā)團(tuán)隊(duì)是成功實(shí)施DevOps的關(guān)鍵。

  根據(jù)康威定律：軟件團(tuán)隊(duì)開發(fā)的產(chǎn)品是對(duì)公司組織架構(gòu)的反映。

  所以根據(jù)公司情況調(diào)整組織結(jié)構(gòu)是首要條件，它將直接影響到需求、設(shè)計(jì)和開發(fā)階段的效率、以及溝通的成本。

  關(guān)于團(tuán)隊(duì)的溝通成本在《人月神話》中有個(gè)很好的計(jì)算公式：溝通成本 = n(n-1)/2，其中n為人數(shù)，所以溝通成本將隨著組織人員的增加而呈指數(shù)級(jí)增長(zhǎng)。而小而快的敏捷團(tuán)隊(duì)如何劃分，我將在后面“DevOps的具體實(shí)施方法”一節(jié)中詳細(xì)介紹。

• 持續(xù)交付部署：實(shí)現(xiàn)應(yīng)用程序的自動(dòng)化構(gòu)建、部署、測(cè)試和發(fā)布。

  通過技術(shù)工具，把傳統(tǒng)的手工操作轉(zhuǎn)變?yōu)樽詣?dòng)化流程，這不僅有利于提高產(chǎn)品開發(fā)、運(yùn)維部署的效率，還將減少人為因素引起的失誤和事故，提早發(fā)現(xiàn)問題并及時(shí)地解決問題，這樣也保證了產(chǎn)品的質(zhì)量。下圖展示了DevOps自動(dòng)化的流程：

  

  此圖來自我的新書《分布式服務(wù)架構(gòu)：原理、設(shè)計(jì)與實(shí)戰(zhàn)》，書中也有具體介紹持續(xù)交付部署的細(xì)節(jié)內(nèi)容。

• IT服務(wù)管理：可持續(xù)的、高可用的IT服務(wù)是保障業(yè)務(wù)正常的關(guān)鍵要素，它與業(yè)務(wù)是一個(gè)整體。

  IT服務(wù)管理（ITSM）直接影響產(chǎn)品運(yùn)營(yíng)的整個(gè)生命周期，傳統(tǒng)的IT服務(wù)管理（像ITIL）在生產(chǎn)中做的非常好了，但是它對(duì)于DevOps來說又顯得過于繁瑣，所以有必要為DevOps創(chuàng)建一個(gè)只關(guān)注業(yè)務(wù)持續(xù)性的ITMS，它只需要很少的必要資源來為相應(yīng)的業(yè)務(wù)提供服務(wù)，ITMS更多地從業(yè)務(wù)角度考慮了。

  注：白話解釋下什么是IT服務(wù)管理（ITSM），它是傳統(tǒng)的“IT管理”轉(zhuǎn)向?yàn)椤癐T服務(wù)”為主的一種模式，前者可能更關(guān)注具體服務(wù)器管理、網(wǎng)絡(luò)管理和系統(tǒng)軟件安裝部署等工作；而后者更關(guān)注流程的規(guī)范化、標(biāo)準(zhǔn)化，明確定義各個(gè)流程的目標(biāo)和范圍、成本和效益、運(yùn)營(yíng)步驟、關(guān)鍵成功因素和績(jī)效指標(biāo)、有關(guān)人員的責(zé)權(quán)利，以及各個(gè)流程之間的關(guān)系等，比如建立線上事故解決流程、服務(wù)配置管理流程等； 
  而光有流程還不夠，因?yàn)榱鞒讨饕荌T服務(wù)提供方內(nèi)部使用的，客戶對(duì)他們并不感興趣，所以還需將這些流程按需打包成特定的IT服務(wù)，然后提供給客戶使用，比如在云平臺(tái)上購(gòu)買一臺(tái)虛擬云主機(jī)一樣。

• 精益管理：建立一個(gè)流水線式的IT服務(wù)鏈，打通開發(fā)與運(yùn)維的鴻溝，實(shí)現(xiàn)開發(fā)運(yùn)維一體化的敏捷模式。

  精益生產(chǎn)主要來源于豐田生產(chǎn)方式 (TPS)的生產(chǎn)哲學(xué)，它以降低浪費(fèi)、提升整體客戶價(jià)值而聞名，它主要利用優(yōu)化自動(dòng)化流程來提高生產(chǎn)率、降低浪費(fèi)。所以精益生產(chǎn)的精髓是即時(shí)制（JIT）和自動(dòng)化（Jidoka）。

  JIT（Just In time）：JIT用一句話描述就是消耗最少的必要資源，以正確的數(shù)量，生產(chǎn)和運(yùn)送正確的零件。在這種模式下工作，可以最大程度上降低庫(kù)存，防止過早或者過度生產(chǎn)。大多數(shù)公司更傾向用庫(kù)存來避免潛在的停線風(fēng)險(xiǎn)，而豐田卻反其道而行之。通過減少庫(kù)存“逼迫”對(duì)生產(chǎn)中產(chǎn)生的問題做及時(shí)且有效的反應(yīng)。當(dāng)然JIT這一模式對(duì)解決問題的能力是相當(dāng)大的考驗(yàn)，在能力不足的情況下，會(huì)有相當(dāng)大的斷線風(fēng)險(xiǎn)。

  Jidoka（Build in quality）：自動(dòng)化，日語表示為“自働化”，字面含義是自動(dòng)化，日語里表示為“自動(dòng)化”，而在豐田TPS系統(tǒng)里，特意給“動(dòng)”字加上了“人”字旁變成了“働”，換句話說，TPS/精益生產(chǎn)渴望生產(chǎn)的過程控制能像“人”一樣智能，在第一時(shí)間就異常情況下自動(dòng)關(guān)閉。這種自動(dòng)停機(jī)功能可以防止壞件流入下游，防止機(jī)器在錯(cuò)誤的生產(chǎn)狀態(tài)下造成損壞，也可以讓人更好的在當(dāng)前錯(cuò)誤狀態(tài)下進(jìn)行故障分析。當(dāng)設(shè)備能夠做到自動(dòng)分析故障時(shí)，就可以將監(jiān)管機(jī)器的“人”真正解放出來，做到對(duì)人力成本的節(jié)省。 
  ——來自知乎

下圖展示了豐田TPS（Toyota Production System）手冊(cè)中的精益小屋：

而精益軟件開發(fā)是精益生產(chǎn)和實(shí)踐在軟件開發(fā)領(lǐng)域的應(yīng)用，總結(jié)為如下七條原則：

1. 消除浪費(fèi)

2. 增強(qiáng)學(xué)習(xí)

3. 盡量延遲決定

4. 盡快發(fā)布

5. 下放權(quán)力

6. 嵌入質(zhì)量

7. 全局優(yōu)化

精益管理貫穿于整個(gè)DevOps階段，它鼓勵(lì)主動(dòng)發(fā)現(xiàn)問題，不斷的優(yōu)化流程，從而達(dá)到持續(xù)交付、快速反饋、降低風(fēng)險(xiǎn)和保障質(zhì)量的目的。接下來讓我們看看DevOps具體的實(shí)現(xiàn)方法。

實(shí)施DevOps的具體方法

• 建立快速敏捷團(tuán)隊(duì)

  根據(jù)之前介紹的康威定律，我們可以看下目前公司中的項(xiàng)目團(tuán)隊(duì)結(jié)構(gòu)是怎么的，如下圖所示：

  

  我相信這不僅僅是我們公司這樣的結(jié)構(gòu)，而是目前大多數(shù)IT互聯(lián)網(wǎng)公司普遍的分層結(jié)構(gòu)吧，它們一般分為七大部門：產(chǎn)品策劃、設(shè)計(jì)美術(shù)、前端工程師、后端工程師、測(cè)試工程師、運(yùn)維&DBA和市場(chǎng)運(yùn)營(yíng)等。各部門之間天然的形成了溝通障礙墻，相互之間主要以郵件和會(huì)議的形式溝通，效率低下、需求變更困難、很難快速響應(yīng)市場(chǎng)變化和持續(xù)交付高品質(zhì)的產(chǎn)品。

那么如何調(diào)整組織結(jié)構(gòu)，建立一個(gè)Scrum團(tuán)隊(duì)呢？（什么是Scrum請(qǐng)參考維基百科）

我們會(huì)按照業(yè)務(wù)功能劃分團(tuán)隊(duì)，建立溝通群組，設(shè)置產(chǎn)品負(fù)責(zé)人（一個(gè)策劃人員）、Scrum Master（我們一般選擇測(cè)試人員擔(dān)任，測(cè)試驅(qū)動(dòng)開發(fā)模式）和開發(fā)者團(tuán)隊(duì)（前端工程師、后端工程師、測(cè)試各一名），最后的組織結(jié)構(gòu)和系統(tǒng)架構(gòu)如下圖所示：

一個(gè)高效的敏捷團(tuán)隊(duì)是DevOps能落地的保障，那么自動(dòng)化流程就是保證產(chǎn)品快速交付和持續(xù)部署的有效機(jī)制，接下來為大家介紹我們是如何實(shí)現(xiàn)自動(dòng)化流程的？

• 實(shí)現(xiàn)自動(dòng)化的流程

  直接看圖說話吧，以下為一個(gè)完整DevOps的Pipeline：

  

1. 提交：工程師將代碼在本地測(cè)試后，提交到版本控制系統(tǒng)，如 Git代碼倉(cāng)庫(kù)中。

2. 構(gòu)建：持續(xù)整合系統(tǒng)（如Jenkins CI），在檢測(cè)到版本控制系統(tǒng)更新時(shí)，便自動(dòng)從Git代碼倉(cāng)庫(kù)里拉取最新的代碼，進(jìn)行編譯、構(gòu)建。

3. 單元測(cè)試：Jenkins完成編譯構(gòu)建后，會(huì)自動(dòng)執(zhí)行指定的單元測(cè)試代碼。

4. 部署到測(cè)試環(huán)境：在完成單元測(cè)試后，Jenkins可以將應(yīng)用程序部署到與生產(chǎn)環(huán)境相近的測(cè)試環(huán)境中進(jìn)行測(cè)試。

5. 預(yù)生產(chǎn)環(huán)境測(cè)試：在預(yù)生產(chǎn)測(cè)試環(huán)境里，可以進(jìn)行一些最后的自動(dòng)化測(cè)試，例如使用Appium自動(dòng)化測(cè)試工具進(jìn)行測(cè)試，以及與實(shí)際情況類似的一些測(cè)試可由開發(fā)人員或客戶人員手動(dòng)進(jìn)行測(cè)試。

6. 部署到生產(chǎn)環(huán)境：通過所有測(cè)試后，便可以使用灰度更新將最新的版本部署到實(shí)際生產(chǎn)環(huán)境里。

而實(shí)現(xiàn)DevOps自動(dòng)化流水線所需要哪些技術(shù)，它們又是如何配合使用的？帶著這些問題，我將在DevOps的技術(shù)棧一節(jié)中詳細(xì)為大家介紹。接下來讓我們看看DevOps在游戲項(xiàng)目中實(shí)施所遇到的問題吧。

DevOps在游戲項(xiàng)目遇到的問題

問題一：游戲服務(wù)很難實(shí)現(xiàn)無狀態(tài)化

游戲服務(wù)架構(gòu)與互聯(lián)網(wǎng)架構(gòu)差別還是很大的，由于游戲?qū)?shí)時(shí)性要求較高，所以很多游戲服很難使用分布式集中緩存，從而很難現(xiàn)實(shí)游戲服的無狀態(tài)化，所以在互聯(lián)網(wǎng)中成熟的微服務(wù)解決方案就不能直接應(yīng)用到游戲中了，我會(huì)在后面具體介紹游戲與互聯(lián)網(wǎng)的對(duì)比，以及游戲服如何拆分和解耦的。

問題二：人手緊缺

人員緊缺其實(shí)是很多公司的普遍問題，然而我經(jīng)歷過的游戲公司中，一個(gè)手游項(xiàng)目人員配備通常為：前端5-6人、后端3-4人、測(cè)試1-2人和1個(gè)運(yùn)維。所以就很難有專門的人員去負(fù)責(zé)DevOps的自動(dòng)化流程實(shí)現(xiàn)等了，只能抽空加班由自己推動(dòng)落實(shí)。

問題三：跨多部門協(xié)作，前期溝通培訓(xùn)成本高

在轉(zhuǎn)型的過程中，由于之前各部門間溝通協(xié)作隔著道“墻”，人員知識(shí)體系和認(rèn)知不同，所以團(tuán)隊(duì)成員不支持或配合緩慢等。我們可以通過鼓勵(lì)合作責(zé)任共擔(dān)、建立自動(dòng)化流程、推倒部門墻、營(yíng)造DevOps文化獎(jiǎng)勵(lì)積極主動(dòng)轉(zhuǎn)變的行為、改變風(fēng)險(xiǎn)管理方式建立對(duì)失敗的寬容環(huán)境。

問題四：前期投入工作量大而見效少

項(xiàng)目初期人員不足工期又緊的時(shí)候，還要做基礎(chǔ)設(shè)施建設(shè)、人員溝通培訓(xùn)等，投入成本高而見效少，很容易讓領(lǐng)導(dǎo)層失去信心。所以DevOps的實(shí)施也需要分階段進(jìn)行，逐步完善流程，以每階段滿足當(dāng)前業(yè)務(wù)需求為基本準(zhǔn)則，這也正是益精軟件的原則。我在工作中一般分為三個(gè)時(shí)期：產(chǎn)品原型期、產(chǎn)品測(cè)試期和產(chǎn)品運(yùn)營(yíng)期。（請(qǐng)結(jié)合前面自動(dòng)化流程一節(jié)中的“DevOps Pipeline”流水線圖看下面三個(gè)時(shí)期的工作）

• 產(chǎn)品原型期：此時(shí)處于開發(fā)的前期，所以我們一般只需要實(shí)現(xiàn)Git代碼倉(cāng)庫(kù)、Jenkins CI集成和使用FindBugs或SonarQube執(zhí)行靜態(tài)代碼分析等。

• 產(chǎn)品測(cè)試期：在前面的基礎(chǔ)上繼續(xù)實(shí)現(xiàn)Jenkins集成Gradle實(shí)現(xiàn)自動(dòng)構(gòu)建打包、單元測(cè)試、部署到測(cè)試環(huán)境等流程。

• 產(chǎn)品運(yùn)營(yíng)期：最后完善流水線，實(shí)現(xiàn)自動(dòng)部署預(yù)生產(chǎn)環(huán)境和生產(chǎn)環(huán)境，實(shí)現(xiàn)灰度更新等。

DevOps的思想先進(jìn)、理念完美，是目前為止我覺得最好的解決方案，不過DevOps最終能夠落地，很大程度上還是歸功于它有一整套的技術(shù)和開源工具。接下來讓我們一起看看DevOps想著的技術(shù)棧吧。

技術(shù)棧

本節(jié)內(nèi)容如果展開的話涉及太多，我將概略地為大家介紹下目前常見的一些開源DevOps技術(shù)工具，大家可以根據(jù)自己的需求選擇使用，當(dāng)然也可以使用像VSTS（Visual Studio Team Services）這樣的集成團(tuán)隊(duì)環(huán)境。

其中有些內(nèi)容在我的新書中有詳細(xì)介紹，如代碼倉(cāng)庫(kù)管理、虛擬機(jī)與容器化、持續(xù)集成&持續(xù)部署工具Jenkins、配置管理工具SaltStack。

敏捷管理工具

• Trello

• Teambition

• Worktile

• Tower

以上工具使用大同小異，選擇一款適合自己團(tuán)隊(duì)的就好。我們公司主要使用的是Teambition，截張效果圖如下：

產(chǎn)品&質(zhì)量管理

• confluence

• 禪道

• Jira

• Bugzila

其中confluence和禪道主要是產(chǎn)品的需求、定義、依賴和推廣等的全面管理工具；而Jira和Bugzilla是產(chǎn)品的質(zhì)量管理和監(jiān)控能力，包括測(cè)試用例、缺陷跟蹤和質(zhì)量監(jiān)控等。目前我們使用Jira較多。

代碼倉(cāng)庫(kù)管理

• Git

• Gitlab

• Github

Git是一個(gè)開源的分布式版本控制系統(tǒng)；Gitlab和Github是用于倉(cāng)庫(kù)管理系統(tǒng)的開源項(xiàng)目，它們使用Git作為代碼管理工具，并在此基礎(chǔ)上搭建起來的web服務(wù)。我們主要使用的是Git和Gitlab。

開發(fā)流程規(guī)范

• Git Flow

  Git Flow是構(gòu)建在Git之上的一個(gè)組織軟件開發(fā)活動(dòng)的模型，是在Git之上構(gòu)建的一項(xiàng)軟件開發(fā)最佳實(shí)踐。Git Flow是一套使用Git進(jìn)行源代碼管理時(shí)的一套行為規(guī)范和簡(jiǎn)化部分Git操作的工具。Git Flow模型如下圖：

  

• Github Flow

  Github Flow是Git Flow的一個(gè)更簡(jiǎn)單的替換方案，它只有一個(gè)feature分支和一個(gè)master分支，簡(jiǎn)單而干凈。Github Flow模型如下圖：

• Gitlab Flow

  GitHub Flow認(rèn)為你可以通過合并feature分支直接把代碼部署到線上。Gitlab Flow模型如下圖：

  

自動(dòng)化構(gòu)建腳本

• Gradle

• Maven

• SBT

• ANT

我目前主要使用Gradle和Maven，而Gradle是一個(gè)基于Apache Ant和Apache Maven概念的項(xiàng)目自動(dòng)化構(gòu)建工具。它使用一種基于Groovy的特定領(lǐng)域語言(DSL)來聲明項(xiàng)目設(shè)置，拋棄了基于XML的各種繁瑣配置。面向Java應(yīng)用為主。當(dāng)前其支持的語言限于Java、Groovy、Kotlin和Scala。

虛擬機(jī)與容器化

• VMware

• VirtualBox

• Vagrant

• Docker

VMware和VirtualBox是最常用的虛擬機(jī)，支持非常多的平臺(tái)，而Vagrant是構(gòu)建在虛擬化技術(shù)之上的虛擬機(jī)運(yùn)行環(huán)境管理工具。通過Vagrant可以方便實(shí)現(xiàn)的對(duì)虛擬機(jī)的管理，包括建立和刪除虛擬機(jī)、配置虛擬機(jī)運(yùn)行參數(shù)、管理虛擬機(jī)運(yùn)行狀態(tài)、自動(dòng)化配置和安裝開發(fā)環(huán)境必須的各類軟件、打包和分發(fā)虛擬機(jī)運(yùn)行環(huán)境等。

Docker是一個(gè)開源的應(yīng)用容器引擎，它讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個(gè)可移植的容器中，然后發(fā)布到任何流行的Linux機(jī)器上，也可以實(shí)現(xiàn)虛擬化。

持續(xù)集成（CI）&持續(xù)部署（CD）

• Jenkins

• Hudson

• Travis CI

• CircleCI

Jenkins是一個(gè)開源軟件項(xiàng)目，是基于Java開發(fā)的一種持續(xù)集成工具，用于監(jiān)控持續(xù)重復(fù)的工作，旨在提供一個(gè)開放易用的軟件平臺(tái)，使軟件的持續(xù)集成變成可能，它的前身為Hudson。

Travis CI 是目前新興的開源持續(xù)集成構(gòu)建項(xiàng)目，它與jenkins很明顯的區(qū)別在于采用yaml格式，簡(jiǎn)潔清新獨(dú)樹一幟。

CircleCI是一個(gè)為web應(yīng)用開發(fā)者提供服務(wù)的持續(xù)集成平臺(tái)，主要為開發(fā)團(tuán)隊(duì)提供測(cè)試，持續(xù)集成，以及代碼部署等服務(wù)。

自動(dòng)化測(cè)試

• Appium

  Appium是一個(gè)移動(dòng)端的自動(dòng)化框架，可用于測(cè)試原生應(yīng)用，移動(dòng)網(wǎng)頁(yè)應(yīng)用和混合型應(yīng)用，且是跨平臺(tái)的?？捎糜贗OS和Android以及firefox的操作系統(tǒng)。

• Selenium

  Selenium 測(cè)試直接在瀏覽器中運(yùn)行，就像真實(shí)用戶所做的一樣。Selenium 測(cè)試可以在 Windows、Linux 和 Macintosh上的 Internet Explorer、Mozilla 和 Firefox 中運(yùn)行。

• Mock測(cè)試

  Mock測(cè)試就是在測(cè)試過程中，對(duì)于某些不容易構(gòu)造或者不容易獲取的對(duì)象，用一個(gè)虛擬的對(duì)象來創(chuàng)建以便測(cè)試的測(cè)試方法。這個(gè)虛擬的對(duì)象就是Mock對(duì)象，Mock對(duì)象就是真實(shí)對(duì)象在調(diào)試期間的代替品。Java中的Mock框架常用的有EasyMock和Mockito等。

• 消費(fèi)者驅(qū)動(dòng)契約測(cè)試

  契約測(cè)試是一種針對(duì)外部服務(wù)的接口進(jìn)行的測(cè)試，它能夠驗(yàn)證服務(wù)是否滿足消費(fèi)方期待的契約。當(dāng)一些消費(fèi)方通過接口使用某個(gè)組件的提供的行為時(shí)，它們之間就產(chǎn)生了契約。這個(gè)契約包含了對(duì)輸入和輸出的數(shù)據(jù)結(jié)構(gòu)的期望，性能以及并發(fā)性。而PACT是目前比較流的消費(fèi)者驅(qū)動(dòng)契約測(cè)試框架。

自動(dòng)化運(yùn)維工具

• Ansible

• Puppet

• Chef

IT運(yùn)維自動(dòng)化是指將IT運(yùn)維中日常的、大量的重復(fù)性工作自動(dòng)化，把過去的手工執(zhí)行轉(zhuǎn)為自動(dòng)化操作。自動(dòng)化是IT運(yùn)維工作的升華，IT運(yùn)維自動(dòng)化不單純是一個(gè)維護(hù)過程，更是一個(gè)管理的提升過程，是IT運(yùn)維的最高層次，也是未來的發(fā)展趨勢(shì)。下圖為常用自動(dòng)化運(yùn)維工具對(duì)比：

監(jiān)控管理工具

• Zabbix

  Zabbix是一個(gè)基于WEB界面的提供分布式系統(tǒng)監(jiān)視以及網(wǎng)絡(luò)監(jiān)視功能的企業(yè)級(jí)開源解決方案。

• ELK Stack日志分析系統(tǒng)

  ELK Stack是開源日志處理平臺(tái)解決方案，背后的商業(yè)公司是Elastic。它由日志采集解析工具 Logstash、基于 Lucene 的全文搜索引擎 Elasticsearch、分析可視化平臺(tái) Kibana三部分組成。

• 云監(jiān)控（如Amazon CloudWatch）

  Amazon CloudWatch 是一項(xiàng)針對(duì) AWS 云資源和在 AWS 上運(yùn)行的應(yīng)用程序進(jìn)行監(jiān)控的服務(wù)。您可以使用 Amazon CloudWatch 收集和跟蹤各項(xiàng)指標(biāo)、收集和監(jiān)控日志文件、設(shè)置警報(bào)以及自動(dòng)應(yīng)對(duì) AWS 資源的更改

游戲架構(gòu)

游戲行業(yè)與互聯(lián)網(wǎng)行業(yè)的對(duì)比

• 項(xiàng)目迭代周期對(duì)比

  互聯(lián)網(wǎng)的迭代模式

  

  游戲項(xiàng)目的開發(fā)周期

通過上面的比對(duì)，我們可以看出互聯(lián)網(wǎng)項(xiàng)目每次的需求迭代可以更敏捷、更快速，因?yàn)樗梢园汛蟮男枨蟛鸱譃槎鄠€(gè)小的具體實(shí)現(xiàn)，這樣能保證不斷地持續(xù)交付和部署。

而游戲相比互聯(lián)網(wǎng)的迭代就會(huì)困難些、時(shí)間周期更長(zhǎng)些，因?yàn)橐豢钣螒蚰荛_始交付給用戶，最基礎(chǔ)的功能和玩法都要完備了才能測(cè)試和使用。

• 請(qǐng)求通信機(jī)制對(duì)比

  

互聯(lián)網(wǎng)中一般為請(qǐng)求-響應(yīng)模式，通常情況下每次請(qǐng)求都是同步阻塞方式；而游戲中大多為請(qǐng)求-推送模式，不僅推送自己，還推送給游戲中其他的用戶，游戲中每次請(qǐng)求都為異步非阻塞方式。

小結(jié)：互聯(lián)網(wǎng)服務(wù)器和游戲服務(wù)器最大的區(qū)別實(shí)際上就在于“狀態(tài)”，游戲服務(wù)器的狀態(tài)是實(shí)時(shí)快速變化的、可以容忍丟失的、需要大量廣播同步的；而互聯(lián)網(wǎng)服務(wù)器的狀態(tài)一般是持久化的、不容忍丟失的、只和特定客戶端相關(guān)的。所以在游戲中實(shí)現(xiàn)DevOps的難度比互聯(lián)網(wǎng)大得多，而互聯(lián)網(wǎng)成熟的實(shí)現(xiàn)方案也不能完全的照搬照抄到游戲中來。接下來我將從游戲構(gòu)架—DevOps實(shí)施的源頭—來分析介紹常見游戲服務(wù)架構(gòu)是什么樣的？

常見游戲服務(wù)架構(gòu)分析–DevOps根源

• 休息卡牌游戲

• 這類游戲一般采用http通信模式，它的架構(gòu)和常用的web服務(wù)器架構(gòu)差不多，使用redis集中式緩存保存游戲狀態(tài)，這樣就能通過nginx進(jìn)行負(fù)載，游戲服可以支持無限水平擴(kuò)展。

• 開房間游戲

  

  這類型的游戲一般來說服務(wù)器端會(huì)分為兩個(gè)部分：一是大廳服務(wù)器，一是房間服務(wù)器。大廳服務(wù)器是一個(gè)巨大的廣播集群，負(fù)責(zé)不太實(shí)時(shí)的數(shù)據(jù)傳輸和查詢。房間服務(wù)器是一組可以快速租用、退還的小型實(shí)時(shí)廣播服務(wù)進(jìn)程。

  在大廳服務(wù)器中，所有在線的玩家，都按其ID來分布在多個(gè)進(jìn)程中的一個(gè)，在玩家之間的查詢、廣播操作時(shí)，采用多個(gè)服務(wù)器并行操作，最后匯總結(jié)果的方式來提供。這樣的操作延遲是會(huì)比較高，但是能讓海量的用戶數(shù)據(jù)存儲(chǔ)到不同的機(jī)器上；而房間服務(wù)器則只負(fù)責(zé)提供具體的游戲廣播功能，一旦玩家組成了群組進(jìn)入，大廳服務(wù)器會(huì)拷貝數(shù)據(jù)到房間服務(wù)器，而房間服務(wù)器就只對(duì)這幾個(gè)玩家負(fù)責(zé)了，游戲結(jié)束則清理掉這些玩家數(shù)據(jù)，準(zhǔn)備新的游戲。

• 分服游戲

  

  盡管分服的游戲模型已經(jīng)運(yùn)營(yíng)了很多年，但是有一些游戲運(yùn)營(yíng)商還是希望能讓盡量多的玩家一起玩，因?yàn)榫W(wǎng)游的人氣越活躍，產(chǎn)生的交互越多，游戲的樂趣也就越多，所以就要求能開發(fā)出滿足大量用戶在線互動(dòng)的游戲服務(wù)器模型——全服全線模型。

  SOA架構(gòu)模式是一個(gè)經(jīng)典的分布式軟件架構(gòu)模式，服務(wù)之間使用RPC運(yùn)程調(diào)用功能，而服務(wù)的注冊(cè)和發(fā)現(xiàn)則使用ZooKeeper這樣的目錄服務(wù)器。這樣游戲服務(wù)就拆分為三層結(jié)構(gòu)：最前邊的網(wǎng)關(guān)（gate）服務(wù)器、中間為各游戲服務(wù)器（gameServer），最后邊的數(shù)據(jù)庫(kù)（DB）服務(wù)器。這樣把網(wǎng)絡(luò)功能單獨(dú)提取出來，讓用戶統(tǒng)一去連接一個(gè)網(wǎng)關(guān)服務(wù)器，再由網(wǎng)關(guān)服務(wù)器轉(zhuǎn)發(fā)數(shù)據(jù)到后端游戲服務(wù)器。而游戲服務(wù)器之間數(shù)據(jù)交換也統(tǒng)一連接到網(wǎng)關(guān)服進(jìn)行交換。所有與DB交互的都連接到DB服務(wù)器來代理處理。

小結(jié)：現(xiàn)在游戲服務(wù)器變得越來越大，不同游戲其實(shí)又具有很多相同的功能，所以如何把游戲服務(wù)進(jìn)行拆分解耦，從而實(shí)現(xiàn)游戲的服務(wù)化就變得相當(dāng)重要了，接下來我將進(jìn)一步介紹游戲服務(wù)是如何拆分的？

游戲服務(wù)的解耦–分而治之思想

• 業(yè)務(wù)層面拆分

• 從業(yè)務(wù)層面，其實(shí)所有的RPG游戲都具有武將、屬性、背包、任務(wù)和技術(shù)等五大基礎(chǔ)系統(tǒng)，而各游戲的差異化大多在不同的玩法系統(tǒng)，業(yè)務(wù)系統(tǒng)和活動(dòng)系統(tǒng)也有很多相似的地方。板面的做法和配料

• 功能層面拆分

  

  從功能層面，像登陸系統(tǒng)、客服系統(tǒng)、統(tǒng)計(jì)系統(tǒng)和監(jiān)控系統(tǒng)我們也都可以做為通用的游戲服務(wù)，提供給各游戲項(xiàng)目使用，從而實(shí)現(xiàn)游戲業(yè)的SAAS平臺(tái)。

• 多維度架構(gòu)

  一套游戲平臺(tái)面向不同的部門和人員，所以也需要從不同的維度考慮和構(gòu)建，從而盡量滿足大部分人的需求和便利。

上述就是小編為大家分享的如何看待DevOps了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

網(wǎng)頁(yè)標(biāo)題：如何看待DevOps
本文來源：http://jinyejixie.com/article8/gdpeip.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、網(wǎng)站內(nèi)鏈、Google、面包屑導(dǎo)航、定制開發(fā)、移動(dòng)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)