前言

DevOps方案實(shí)施在互聯(lián)網(wǎng)行業(yè)中已經(jīng)相對(duì)成熟了鄙才，而在游戲行業(yè)中還處在起步的初級(jí)階段（據(jù)個(gè)人了解的身邊游戲公司情況）厢钧，而自己又對(duì)DevOps有一定的研究與實(shí)踐，也想本著學(xué)以致用的思想懦底，結(jié)合了公司游戲類型和業(yè)務(wù)方向摸索了一套游戲行業(yè)的DevOps實(shí)施落地方案雅任。該方案不一定是很好的懈息，不過它幫助我們提高了開發(fā)的效率和規(guī)范了流程肾档，減少了人為的失誤率和事故率。

前陣子受「中國(guó)持續(xù)交付大會(huì)」主辦方的邀請(qǐng)辫继，有幸能在ThoughtWorks辦公室與各行業(yè)DevOps精英們一起探討“DevOps在游戲中的具體實(shí)現(xiàn)”怒见，發(fā)張當(dāng)時(shí)活動(dòng)的照片看看現(xiàn)場(chǎng)有多火爆。

DevOps游戲中的實(shí)踐

DevOps游戲中的實(shí)踐

現(xiàn)場(chǎng)還抽獎(jiǎng)贈(zèng)送了我和朋友合著的《分布式服務(wù)架構(gòu)：原理姑宽、設(shè)計(jì)與實(shí)戰(zhàn)》新書遣耍，感興趣的可以掃描二維碼購(gòu)買哦（一不小心打了個(gè)廣告嘿嘿）。

《分布式服務(wù)架構(gòu)：原理炮车、設(shè)計(jì)與實(shí)戰(zhàn)》

接下來(lái)我將從“DevOps理念”舵变、“DevOps技術(shù)棧”和“游戲系統(tǒng)架構(gòu)”三個(gè)方面具體分析如何進(jìn)行游戲的DevOps實(shí)踐落地瘦穆。

DevOps理念

DevOps究竟是什么

DevOps（Development和Operations的組合詞）是一種重視“軟件開發(fā)人員（Dev）”和“IT運(yùn)維技術(shù)人員（Ops）”之間溝通合作的文化纪隙、運(yùn)動(dòng)或慣例。透過自動(dòng)化“軟件交付”和“架構(gòu)變更”的流程扛或，來(lái)使得構(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)槭裁葱枰兀克o我們又帶來(lái)了哪些好處朋腋？

為什么需要DevOps

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

VUCA時(shí)代

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)系的混雜幻梯。

接下來(lái)我將從“產(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)出了一輛漂亮的小轎車交付給了用戶，終于讓用戶滿意了热某。

DevOps模式

• 現(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ù)也變得越來(lái)越復(fù)雜茬底，功能越來(lái)越多，如果整個(gè)系統(tǒng)耦合在一起售睹，則必定會(huì)牽一發(fā)而動(dòng)全身桩警，導(dǎo)致系統(tǒng)維護(hù)起來(lái)相當(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ù)革新的變化：

技術(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í)踐就是具體做事的方法蒲讯，接下來(lái)我就從我在公司中是如何按照理論與實(shí)踐相結(jié)合來(lái)推動(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)新寡痰。

DevOps核心功能

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

DevOps主要知識(shí)體系

• 敏捷管理：一支訓(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)化的流程：

DevOps自動(dòng)化流程

此圖來(lái)自我的新書《分布式服務(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來(lái)說又顯得過于繁瑣，所以有必要為DevOps創(chuàng)建一個(gè)只關(guān)注業(yè)務(wù)持續(xù)性的ITMS愧驱，它只需要很少的必要資源來(lái)為相應(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)主要來(lái)源于豐田生產(chǎn)方式 (TPS)的生產(chǎn)哲學(xué)豹爹，它以降低浪費(fèi)裆悄、提升整體客戶價(jià)值而聞名，它主要利用優(yōu)化自動(dòng)化流程來(lái)提高生產(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ù)存來(lái)避免潛在的停線風(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)化，日語(yǔ)表示為“自働化”要门，字面含義是自動(dòng)化虏肾，日語(yǔ)里表示為“自動(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ī)器的“人”真正解放出來(lái)斩个，做到對(duì)人力成本的節(jié)省胯杭。
——來(lái)自知乎

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

TPS House

而精益軟件開發(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ì)量的目的。接下來(lái)讓我們看看DevOps具體的實(shí)現(xiàn)方法藤肢。

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

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

傳統(tǒng)的組織結(jié)構(gòu)和系統(tǒng)架構(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)如下圖所示：

Scrum團(tuán)隊(duì)和系統(tǒng)架構(gòu)

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

• 實(shí)現(xiàn)自動(dòng)化的流程
  直接看圖說話吧闷盔，以下為一個(gè)完整DevOps的Pipeline：

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ì)為大家介紹。接下來(lái)讓我們看看DevOps在游戲項(xiàng)目中實(shí)施所遇到的問題吧。

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

問題一 游戲服務(wù)很難實(shí)現(xiàn)無(wú)狀態(tài)化：
游戲服務(wù)架構(gòu)與互聯(lián)網(wǎng)架構(gòu)差別還是很大的变骡，由于游戲?qū)?shí)時(shí)性要求較高离赫，所以很多游戲服很難使用分布式集中緩存，從而很難現(xiàn)實(shí)游戲服的無(wú)狀態(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ù)和開源工具。接下來(lái)讓我們一起看看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海蔽，截張效果圖如下：

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ǔ)上搭建起來(lái)的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模型如下圖：

Git Flow模型

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

Github Flow模型

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

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)域語(yǔ)言(DSL)來(lái)聲明項(xiàng)目設(shè)置做瞪，拋棄了基于XML的各種繁瑣配置。面向Java應(yīng)用為主右冻。當(dāng)前其支持的語(yǔ)言限于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)的∧呻剩可用于IOS和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ì)象來(lái)創(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)維的最高層次怕品，也是未來(lái)的發(fā)展趨勢(shì)妇垢。下圖為常用自動(dòng)化運(yùn)維工具對(duì)比：

自動(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)服務(wù)簡(jiǎn)單對(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)方案也不能完全的照搬照抄到游戲中來(lái)捉偏。接下來(lái)我將從游戲構(gòu)架—DevOps實(shí)施的源頭—來(lái)分析介紹常見游戲服務(wù)架構(gòu)是什么樣的倒得？

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

• 休息卡牌游戲

休息游戲架構(gòu)

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

• 開房間游戲

房間模式游戲架構(gòu)

?這類型的游戲一般來(lái)說服務(wù)器端會(huì)分為兩個(gè)部分：一是大廳服務(wù)器菩彬，一是房間服務(wù)器。大廳服務(wù)器是一個(gè)巨大的廣播集群潮梯，負(fù)責(zé)不太實(shí)時(shí)的數(shù)據(jù)傳輸和查詢骗灶。房間服務(wù)器是一組可以快速租用、退還的小型實(shí)時(shí)廣播服務(wù)進(jìn)程秉馏。
在大廳服務(wù)器中矿卑，所有在線的玩家，都按其ID來(lái)分布在多個(gè)進(jìn)程中的一個(gè)沃饶，在玩家之間的查詢母廷、廣播操作時(shí)轻黑，采用多個(gè)服務(wù)器并行操作，最后匯總結(jié)果的方式來(lái)提供琴昆。這樣的操作延遲是會(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)備新的游戲。

• 分服游戲

RPG&SLG分服模式架構(gòu)

分服模型是游戲服務(wù)器中最典型下面，也是歷久最悠久的复颈。其特征是游戲服務(wù)器是一個(gè)個(gè)單獨(dú)的世界，每個(gè)服務(wù)器的帳號(hào)是獨(dú)立的沥割，每臺(tái)服務(wù)器用戶的狀態(tài)都是不一樣的耗啦，一個(gè)服就是一個(gè)平行的世界，各服之間互不相干机杜。

• 全服模式

RPG&SLG全服模式架構(gòu)

盡管分服的游戲模型已經(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ú)提取出來(lái)，讓用戶統(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ù)器來(lái)代理處理诗宣。

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

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

• 業(yè)務(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)

多維度架構(gòu)

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

小結(jié)

本章內(nèi)容較多专控，首先從DevOps的理論開始介紹了抹凳，什么是DevOps，以及我們什么需要它伦腐，然后再結(jié)合實(shí)際一步步地介紹了DevOps的落地實(shí)踐赢底。而DevOps最終能被實(shí)現(xiàn)主要?dú)w功于它擁有豐富的開源技術(shù)工作，所以我們又介紹了目前常用的DevOps技術(shù)棧柏蘑，最后通過對(duì)游戲行業(yè)的分析介紹幸冻，實(shí)現(xiàn)了游戲服務(wù)的拆分，最終從游戲系統(tǒng)構(gòu)架層入手實(shí)現(xiàn)了DevOps在游戲中的落地咳焚。謝謝大家的支持Ｇ⑺稹！