DevOps 在公司專案中的實踐落地--方便自己理解和落地DevOps
DevOps究竟是什麼
DevOps（Development和Operations的組合詞）是一種重視“軟體開發人員（Dev）”和“IT運維技術人員（Ops）”之間溝通合作的文化、運動或慣例。透過自動化“軟體交付”和“架構變更”的流程，來使得構建、測試、釋出軟體能夠更加地快捷、頻繁和可靠。——維基百科
DevOps是一種文化轉變，或者說是一個鼓勵更好地交流和協作（即團隊合作）以便於更快地構建可靠性更高、質量更好的軟體的運動。——Mike Kavis
Mike Kavis是美國Cloud Technology Partners公司的副總裁兼首席架構師，他也更加詳細地描述介紹說：DevOps是軟體開發生命週期（SDLC）從瀑布式到敏捷再到精益的發展。DevOps超越了敏捷，它的關注點是從SDLC中移除浪費。通常情況下，發現浪費或者瓶頸的形式包括：不一致的環境，人工的構建和部署流程，差的質量和測試實踐，IT部門之間缺少溝通和理解，頻繁的中斷和失敗的協定以及那些需要珍貴的資源、花費重要的時間和金錢才能保持系統執行的全套問題。
他還看到另一個重複浪費是：一個DevOps團隊的第一步通常是決定他們是否應該使用Chef或者Puppet（或者是Salt、Ansible等其他任何熱門的東西）。他們甚至還沒有定義自己打算解決的問題，即使他們手頭的工具可以解決它們。這些團隊通常會緊張地構建數千行指令碼，但是這就產生了一個問題：“我們的職責是編寫Chef指令碼還是通過質量更好、更穩定的產品更快地進入市場？”。在大多數情況下，這些團隊會將自己逼入絕境，大量的專有指令碼實際上是增加了系統的浪費，而隱藏在DevOps運動之後的驅動力是從系統中移除浪費，這些團隊並沒有做到這一點。Mike Kavis原文
而目前對 DevOps 有太多的說法和定義，不過它們都有一個共同的思想：“解決開發者與運維者之間曾經不可逾越的鴻溝，增強開發者與運維者之間的溝通和交流”。而我個人認為，DevOps 可以用一個公式表達：
文化觀念的改變 + 自動化工具 = 不斷適應快速變化的市場
其核心價值在於以下兩點：
更快速地交付, 響應市場的變化。
更多地關注業務的改進與提升。
當理解了什麼是DevOps後，那我們為什麼需要它呢？它給我們又帶來了哪些好處？
為什麼需要DevOps
當今世界改變的速度已與過去不同，而每當經歷一個顛覆性的技術革命時，都給這個世界帶來了深刻的變化，大資料、雲端計算、人工智慧、VR/AR和區塊鏈等新興技術推動著世界不斷變化，如何應對這樣一個VUCA時代，讓我們能夠在環境變化的時候快速響應呢？
V=Volatillity（易變性）是變化的本質和動力，也是由變化驅使和催化產生的
U=Uncertainty（不確定性）缺少預見性,缺乏對意外的預期和對事情的理解和意識
C=Complexity（複雜性）企業為各種力量，各種因素，各種事情所困擾。
A=Ambiguity（模糊性）對現實的模糊，是誤解的根源，各種條件和因果關係的混雜。
接下來我將從“產品迭代”和“技術革新”兩個層面分析介紹如何變化的。
產品迭代
我們不管是做網際網路還是做遊戲，其實最終都是在做產品，做一款使用者喜歡的產品。喬布斯有句非常著名的名言：“消費者並不知道自己需要什麼，直到我們拿出自己的產品，他們才發現，這是我想要的東西”。所以喬幫主能夠在一開始的時候就設計好了產品最終的效果，然後按照零部件一步步迭代生產，其步驟可以用下圖所示：
全世界只有一個喬布斯，而在我們現實的產品迭代中卻是這樣的，對話如下：
使用者：我平時上下班都是走路，每天都要走五公里，好辛苦，有沒有辦法幫我設計個工具，解決下我的痛點。
我們思考了下，覺得這個不是很難嘛，可以試下，於是我們討論 -> 設計 -> 開發 -> 測試 -> 交付給使用者了一個滑板。
使用者：這個滑板不好操控，可以給我加個扶手嗎？
然後我們按照使用者新的需求，生產了個滑板車。
使用者：滑板車得滑著走，能不能讓我可以騎著走的。
我們繼續改進產品，生產了個自行車。
使用者：自行車還得登著走，路程遠了也很累。
我們又繼續優化，把它變成了電瓶車。
使用者：電瓶車倒是解決了的需求，不過就是不太安全，能再優化下產品嗎？
經過各種努力我們最後生產出了一輛漂亮的小轎車交付給了使用者，終於讓使用者滿意了。
現實中的使用者其實一開始並不知道自己想要什麼，但是直到看到了我們的產品，他才知道自己不想要什麼。
即讓現實的產品迭代是如此曲折和反覆的，那我們有沒有辦法快速交付價值、靈活響應變化呢？答案就是DevOps，它是面向業務目標，助力業務成功的最佳實踐。
產品的迭代需要DevOps，那麼技術的革新更加促進了DevOps的快速發展和落地實施，下面讓我們一起看一下技術又是如何支援產品的迭代而不斷革新地呢？
技術革新
在以前的系統中業務單一、邏輯簡單、使用者量少，專案團隊的規模一般在 10~30人。而現在的系統要面對不同使用者的定製化推薦等，網際網路連線著人與人、人與物、以及物與物，業務也變得越來越複雜，功能越來越多，如果整個系統耦合在一起，則必定會牽一髮而動全身，導致系統維護起來相當困難。
因此IT技術架構也隨著系統的複雜化而不斷地變化革新，從早期所有服務的All In One發展到現在的微服務架構、從純手動操作到全自動化流程、從單臺物理機到雲平臺，下圖展示了IT技術革新的變化：
現在DevOps已經成為發展的趨勢了，那它又是怎麼實現落地的呢？
如何實現DevOps的落地
知之真切篤實處即是行，行之明覺精察處即是知 —— 明•王守仁《傳習錄》
在些我引用了聖賢王陽明的一句名言，他提倡“知行合一”，通俗的講就是做事情要理論與實踐相結合。我們在實現DevOps落地時也一定要遵循“理論與實踐相結合”的方式進行，理論就是我們做事的指導思想，而實踐就是具體做事的方法，接下來我就從我在公司中是如何按照理論與實踐相結合來推動DevOps落實地。
落實DevOps的指導思想
首先我們還是要回到什麼是DevOps，如果大家忘記了可以回到之前再溫故一下，包括我總結的DevOps公式。
其實DevOps核心思想就是：“快速交付價值，靈活響應變化”。其基本原則如下：
高效的協作和溝通；
自動化流程和工具；
快速敏捷的開發；
持續交付和部署；
不斷學習和創新。
然而這些基本原則又是如何與專案研發息息相關的呢，也就是它們在我們的開發過程中的各個環節是如何體現的？請看下面一張來自《success with enterprise dev-ops - whitepaper》的介紹圖：
敏捷管理：一支訓練有素的敏捷開發團隊是成功實施DevOps的關鍵。
根據康威定律：軟體團隊開發的產品是對公司組織架構的反映。
所以根據公司情況調整組織結構是首要條件，它將直接影響到需求、設計和開發階段的效率、以及溝通的成本。
關於團隊的溝通成本在《人月神話》中有個很好的計算公式：溝通成本 = n(n-1)/2，其中n為人數，所以溝通成本將隨著組織人員的增加而呈指數級增長。而小而快的敏捷團隊如何劃分，我將在後面“DevOps的具體實施方法”一節中詳細介紹。
持續交付部署：實現應用程式的自動化構建、部署、測試和釋出。
通過技術工具，把傳統的手工操作轉變為自動化流程，這不僅有利於提高產品開發、運維部署的效率，還將減少人為因素引起的失誤和事故，提早發現問題並及時地解決問題，這樣也保證了產品的質量。下圖展示了DevOps自動化的流程：
此圖來自我的新書《分散式服務架構：原理、設計與實戰》，書中也有具體介紹持續交付部署的細節內容。
IT服務管理：可持續的、高可用的IT服務是保障業務正常的關鍵要素，它與業務是一個整體。
IT服務管理（ITSM）直接影響產品運營的整個生命週期，傳統的IT服務管理（像ITIL）在生產中做的非常好了，但是它對於DevOps來說又顯得過於繁瑣，所以有必要為DevOps建立一個只關注業務持續性的ITMS，它只需要很少的必要資源來為相應的業務提供服務，ITMS更多地從業務角度考慮了。
注：白話解釋下什麼是IT服務管理（ITSM），它是傳統的“IT管理”轉向為“IT服務”為主的一種模式，前者可能更關注具體伺服器管理、網路管理和系統軟體安裝部署等工作；而後者更關注流程的規範化、標準化，明確定義各個流程的目標和範圍、成本和效益、運營步驟、關鍵成功因素和績效指標、有關人員的責權利，以及各個流程之間的關係等，比如建立線上事故解決流程、服務配置管理流程等；
而光有流程還不夠，因為流程主要是IT服務提供方內部使用的，客戶對他們並不感興趣，所以還需將這些流程按需打包成特定的IT服務，然後提供給客戶使用，比如在雲平臺上購買一臺虛擬雲主機一樣。精益管理：建立一個流水線式的IT服務鏈，打通開發與運維的鴻溝，實現開發運維一體化的敏捷模式。
精益生產主要來源於豐田生產方式 (TPS)的生產哲學，它以降低浪費、提升整體客戶價值而聞名，它主要利用優化自動化流程來提高生產率、降低浪費。所以精益生產的精髓是即時制（JIT）和自動化（Jidoka）。
JIT（Just In time）：JIT用一句話描述就是消耗最少的必要資源，以正確的數量，生產和運送正確的零件。在這種模式下工作，可以最大程度上降低庫存，防止過早或者過度生產。大多數公司更傾向用庫存來避免潛在的停線風險，而豐田卻反其道而行之。通過減少庫存“逼迫”對生產中產生的問題做及時且有效的反應。當然JIT這一模式對解決問題的能力是相當大的考驗，在能力不足的情況下，會有相當大的斷線風險。
Jidoka（Build in quality）：自動化，日語表示為“自働化”，字面含義是自動化，日語裡表示為“自動化”，而在豐田TPS系統裡，特意給“動”字加上了“人”字旁變成了“働”，換句話說，TPS/精益生產渴望生產的過程控制能像“人”一樣智慧，在第一時間就異常情況下自動關閉。這種自動停機功能可以防止壞件流入下游，防止機器在錯誤的生產狀態下造成損壞，也可以讓人更好的在當前錯誤狀態下進行故障分析。當裝置能夠做到自動分析故障時，就可以將監管機器的“人”真正解放出來，做到對人力成本的節省。
——來自知乎
下圖展示了豐田TPS（Toyota Production System）手冊中的精益小屋：
而精益軟體開發是精益生產和實踐在軟體開發領域的應用，總結為如下七條原則：
消除浪費
增強學習
儘量延遲決定
儘快釋出
下放權力
嵌入質量
全域性優化
精益管理貫穿於整個DevOps階段，它鼓勵主動發現問題，不斷的優化流程，從而達到持續交付、快速反饋、降低風險和保障質量的目的。接下來讓我們看看DevOps具體的實現方法。
實施DevOps的具體方法
建立快速敏捷團隊
根據之前介紹的康威定律，我們可以看下目前公司中的專案團隊結構是怎麼的，如下圖所示：
我相信這不僅僅是我們公司這樣的結構，而是目前大多數IT網際網路公司普遍的分層結構吧，它們一般分為七大部門：產品策劃、設計美術、前端工程師、後端工程師、測試工程師、運維&DBA和市場運營等。各部門之間天然的形成了溝通障礙牆，相互之間主要以郵件和會議的形式溝通，效率低下、需求變更困難、很難快速響應市場變化和持續交付高品質的產品。
那麼如何調整組織結構，建立一個Scrum團隊呢？（什麼是Scrum請參考維基百科）
我們會按照業務功能劃分團隊，建立溝通群組，設定產品負責人（一個策劃人員）、Scrum Master（我們一般選擇測試人員擔任，測試驅動開發模式）和開發者團隊（前端工程師、後端工程師、測試各一名），最後的組織結構和系統架構如下圖所示：
一個高效的敏捷團隊是DevOps能落地的保障，那麼自動化流程就是保證產品快速交付和持續部署的有效機制，接下來為大家介紹我們是如何實現自動化流程的？
實現自動化的流程
直接看圖說話吧，以下為一個完整DevOps的Pipeline：
提交：工程師將程式碼在本地測試後，提交到版本控制系統，如 Git程式碼倉庫中。
構建：持續整合系統（如Jenkins CI），在檢測到版本控制系統更新時，便自動從Git程式碼倉庫里拉取最新的程式碼，進行編譯、構建。
單元測試：Jenkins完成編譯構建後，會自動執行指定的單元測試程式碼。
部署到測試環境：在完成單元測試後，Jenkins可以將應用程式部署到與生產環境相近的測試環境中進行測試。
預生產環境測試：在預生產測試環境裡，可以進行一些最後的自動化測試，例如使用Appium自動化測試工具進行測試，以及與實際情況類似的一些測試可由開發人員或客戶人員手動進行測試。
部署到生產環境：通過所有測試後，便可以使用灰度更新將最新的版本部署到實際生產環境裡。
而實現DevOps自動化流水線所需要哪些技術，它們又是如何配合使用的？帶著這些問題，我將在DevOps的技術棧一節中詳細為大家介紹。接下來讓我們看看DevOps在遊戲專案中實施所遇到的問題吧。
DevOps在遊戲專案遇到的問題
問題一：遊戲服務很難實現無狀態化
遊戲服務架構與網際網路架構差別還是很大的，由於遊戲對實時性要求較高，所以很多遊戲服很難使用分散式集中快取，從而很難現實遊戲服的無狀態化，所以在網際網路中成熟的微服務解決方案就不能直接應用到遊戲中了，我會在後面具體介紹遊戲與網際網路的對比，以及遊戲服如何拆分和解耦的。
問題二：人手緊缺
人員緊缺其實是很多公司的普遍問題，然而我經歷過的遊戲公司中，一個手遊專案人員配備通常為：前端5-6人、後端3-4人、測試1-2人和1個運維。所以就很難有專門的人員去負責DevOps的自動化流程實現等了，只能抽空加班由自己推動落實。
問題三：跨多部門協作，前期溝通培訓成本高
在轉型的過程中，由於之前各部門間溝通協作隔著道“牆”，人員知識體系和認知不同，所以團隊成員不支援或配合緩慢等。我們可以通過鼓勵合作責任共擔、建立自動化流程、推倒部門牆、營造DevOps文化獎勵積極主動轉變的行為、改變風險管理方式建立對失敗的寬容環境。
問題四：前期投入工作量大而見效少
專案初期人員不足工期又緊的時候，還要做基礎設施建設、人員溝通培訓等，投入成本高而見效少，很容易讓領導層失去信心。所以DevOps的實施也需要分階段進行，逐步完善流程，以每階段滿足當前業務需求為基本準則，這也正是益精軟體的原則。我在工作中一般分為三個時期：產品原型期、產品測試期和產品運營期。（請結合前面自動化流程一節中的“DevOps Pipeline”流水線圖看下面三個時期的工作）
產品原型期：此時處於開發的前期，所以我們一般只需要實現Git程式碼倉庫、Jenkins CI整合和使用FindBugs或SonarQube執行靜態程式碼分析等。
產品測試期：在前面的基礎上繼續實現Jenkins整合Gradle實現自動構建打包、單元測試、部署到測試環境等流程。
產品運營期：最後完善流水線，實現自動部署預生產環境和生產環境，實現灰度更新等。
DevOps的思想先進、理念完美，是目前為止我覺得最好的解決方案，不過DevOps最終能夠落地，很大程度上還是歸功於它有一整套的技術和開源工具。接下來讓我們一起看看DevOps想著的技術棧吧。
技術棧
本節內容如果展開的話涉及太多，我將概略地為大家介紹下目前常見的一些開源DevOps技術工具，大家可以根據自己的需求選擇使用，當然也可以使用像VSTS（Visual Studio Team Services）這樣的整合團隊環境。
其中有些內容在我的新書中有詳細介紹，如程式碼倉庫管理、虛擬機器與容器化、持續整合&持續部署工具Jenkins、配置管理工具SaltStack。
敏捷管理工具
Trello
Teambition
Worktile
Tower
以上工具使用大同小異，選擇一款適合自己團隊的就好。我們公司主要使用的是Teambition，截張效果圖如下：
產品&質量管理
confluence
禪道
Jira
Bugzila
其中confluence和禪道主要是產品的需求、定義、依賴和推廣等的全面管理工具；而Jira和Bugzilla是產品的質量管理和監控能力，包括測試用例、缺陷跟蹤和質量監控等。目前我們使用Jira較多。
程式碼倉庫管理
Git
Gitlab
Github
Git是一個開源的分散式版本控制系統；Gitlab和Github是用於倉庫管理系統的開源專案，它們使用Git作為程式碼管理工具，並在此基礎上搭建起來的web服務。我們主要使用的是Git和Gitlab。
開發流程規範
Git Flow
Git Flow是構建在Git之上的一個組織軟體開發活動的模型，是在Git之上構建的一項軟體開發最佳實踐。Git Flow是一套使用Git進行原始碼管理時的一套行為規範和簡化部分Git操作的工具。Git Flow模型如下圖：
Github Flow
Github Flow是Git Flow的一個更簡單的替換方案，它只有一個feature分支和一個master分支，簡單而乾淨。Github Flow模型如下圖：
Gitlab Flow
GitHub Flow認為你可以通過合併feature分支直接把程式碼部署到線上。Gitlab Flow模型如下圖：
自動化構建指令碼
Gradle
Maven
SBT
ANT
我目前主要使用Gradle和Maven，而Gradle是一個基於Apache Ant和Apache Maven概念的專案自動化構建工具。它使用一種基於Groovy的特定領域語言(DSL)來宣告專案設定，拋棄了基於XML的各種繁瑣配置。面向Java應用為主。當前其支援的語言限於Java、Groovy、Kotlin和Scala。
虛擬機器與容器化
VMware
VirtualBox
Vagrant
Docker
VMware和VirtualBox是最常用的虛擬機器，支援非常多的平臺，而Vagrant是構建在虛擬化技術之上的虛擬機器執行環境管理工具。通過Vagrant可以方便實現的對虛擬機器的管理，包括建立和刪除虛擬機器、配置虛擬機器執行引數、管理虛擬機器執行狀態、自動化配置和安裝開發環境必須的各類軟體、打包和分發虛擬機器執行環境等。
Docker是一個開源的應用容器引擎，它讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然後釋出到任何流行的Linux機器上，也可以實現虛擬化。
持續整合（CI）&持續部署（CD）
Jenkins
Hudson
Travis CI
CircleCI
Jenkins是一個開源軟體專案，是基於Java開發的一種持續整合工具，用於監控持續重複的工作，旨在提供一個開放易用的軟體平臺，使軟體的持續整合變成可能，它的前身為Hudson。
Travis CI 是目前新興的開源持續整合構建專案，它與jenkins很明顯的區別在於採用yaml格式，簡潔清新獨樹一幟。
CircleCI是一個為web應用開發者提供服務的持續整合平臺，主要為開發團隊提供測試，持續整合，以及程式碼部署等服務。
自動化測試
Appium
Appium是一個移動端的自動化框架，可用於測試原生應用，移動網頁應用和混合型應用，且是跨平臺的。可用於IOS和Android以及firefox的作業系統。
Selenium
Selenium 測試直接在瀏覽器中執行，就像真實使用者所做的一樣。Selenium 測試可以在 Windows、Linux 和 Macintosh上的 Internet Explorer、Mozilla 和 Firefox 中執行。
Mock測試
Mock測試就是在測試過程中，對於某些不容易構造或者不容易獲取的物件，用一個虛擬的物件來建立以便測試的測試方法。這個虛擬的物件就是Mock物件，Mock物件就是真實物件在除錯期間的代替品。Java中的Mock框架常用的有EasyMock和Mockito等。
消費者驅動契約測試
契約測試是一種針對外部服務的介面進行的測試，它能夠驗證服務是否滿足消費方期待的契約。當一些消費方通過介面使用某個元件的提供的行為時，它們之間就產生了契約。這個契約包含了對輸入和輸出的資料結構的期望，效能以及併發性。而PACT是目前比較流的消費者驅動契約測試框架。
自動化運維工具
Ansible
Puppet
Chef
IT運維自動化是指將IT運維中日常的、大量的重複性工作自動化，把過去的手工執行轉為自動化操作。自動化是IT運維工作的昇華，IT運維自動化不單純是一個維護過程，更是一個管理的提升過程，是IT運維的最高層次，也是未來的發展趨勢。下圖為常用自動化運維工具對比：
監控管理工具
Zabbix
Zabbix是一個基於WEB介面的提供分散式系統監視以及網路監視功能的企業級開源解決方案。
ELK Stack日誌分析系統
ELK Stack是開源日誌處理平臺解決方案，背後的商業公司是Elastic。它由日誌採集解析工具 Logstash、基於 Lucene 的全文搜尋引擎 Elasticsearch、分析視覺化平臺 Kibana三部分組成。
雲監控（如Amazon CloudWatch）
Amazon CloudWatch 是一項針對 AWS 雲資源和在 AWS 上執行的應用程式進行監控的服務。您可以使用 Amazon CloudWatch 收集和跟蹤各項指標、收集和監控日誌檔案、設定警報以及自動應對 AWS 資源的更改
遊戲架構
遊戲行業與網際網路行業的對比
專案迭代週期對比
網際網路的迭代模式
遊戲專案的開發週期
通過上面的比對，我們可以看出網際網路專案每次的需求迭代可以更敏捷、更快速，因為它可以把大的需求拆分為多個小的具體實現，這樣能保證不斷地持續交付和部署。
而遊戲相比網際網路的迭代就會困難些、時間週期更長些，因為一款遊戲能開始交付給使用者，最基礎的功能和玩法都要完備了才能測試和使用。
請求通訊機制對比
網際網路中一般為請求-響應模式，通常情況下每次請求都是同步阻塞方式；而遊戲中大多為請求-推送模式，不僅推送自己，還推送給遊戲中其他的使用者，遊戲中每次請求都為非同步非阻塞方式。
小結：網際網路伺服器和遊戲伺服器最大的區別實際上就在於“狀態”，遊戲伺服器的狀態是實時快速變化的、可以容忍丟失的、需要大量廣播同步的；而網際網路伺服器的狀態一般是持久化的、不容忍丟失的、只和特定客戶端相關的。所以在遊戲中實現DevOps的難度比網際網路大得多，而網際網路成熟的實現方案也不能完全的照搬照抄到遊戲中來。接下來我將從遊戲構架—DevOps實施的源頭—來分析介紹常見遊戲服務架構是什麼樣的？
常見遊戲服務架構分析–DevOps根源
休息卡牌遊戲
這類遊戲一般採用http通訊模式，它的架構和常用的web伺服器架構差不多，使用redis集中式快取儲存遊戲狀態，這樣就能通過nginx進行負載，遊戲服可以支援無限水平擴充套件。
開房間遊戲
這型別的遊戲一般來說伺服器端會分為兩個部分：一是大廳伺服器，一是房間伺服器。大廳伺服器是一個巨大的廣播叢集，負責不太實時的資料傳輸和查詢。房間伺服器是一組可以快速租用、退還的小型實時廣播服務程序。
在大廳伺服器中，所有線上的玩家，都按其ID來分佈在多個程序中的一個，在玩家之間的查詢、廣播操作時，採用多個伺服器並行操作，最後彙總結果的方式來提供。這樣的操作延遲是會比較高，但是能讓海量的使用者資料儲存到不同的機器上；而房間伺服器則只負責提供具體的遊戲廣播功能，一旦玩家組成了群組進入，大廳伺服器會拷貝資料到房間伺服器，而房間伺服器就只對這幾個玩家負責了，遊戲結束則清理掉這些玩家資料，準備新的遊戲。
分服遊戲
分服模型是遊戲伺服器中最典型，也是歷久最悠久的。其特徵是遊戲伺服器是一個個單獨的世界，每個伺服器的帳號是獨立的，每臺伺服器使用者的狀態都是不一樣的，一個服就是一個平行的世界，各服之間互不相干。
全服模式
儘管分服的遊戲模型已經運營了很多年，但是有一些遊戲運營商還是希望能讓儘量多的玩家一起玩，因為網遊的人氣越活躍，產生的互動越多，遊戲的樂趣也就越多，所以就要求能開發出滿足大量使用者線上互動的遊戲伺服器模型——全服全線模型。
SOA架構模式是一個經典的分散式軟體架構模式，服務之間使用RPC運程呼叫功能，而服務的註冊和發現則使用ZooKeeper這樣的目錄伺服器。這樣遊戲服務就拆分為三層結構：最前邊的閘道器（gate）伺服器、中間為各遊戲伺服器（gameServer），最後邊的資料庫（DB）伺服器。這樣把網路功能單獨提取出來，讓使用者統一去連線一個閘道器伺服器，再由閘道器伺服器轉發資料到後端遊戲伺服器。而遊戲伺服器之間資料交換也統一連線到閘道器服進行交換。所有與DB互動的都連線到DB伺服器來代理處理。
小結：現在遊戲伺服器變得越來越大，不同遊戲其實又具有很多相同的功能，所以如何把遊戲服務進行拆分解耦，從而實現遊戲的服務化就變得相當重要了，接下來我將進一步介紹遊戲服務是如何拆分的？
遊戲服務的解耦–分而治之思想
業務層面拆分
從業務層面，其實所有的RPG遊戲都具有武將、屬性、揹包、任務和技術等五大基礎系統，而各遊戲的差異化大多在不同的玩法系統，業務系統和活動系統也有很多相似的地方。板面的做法和配料
功能層面拆分
從功能層面，像登陸系統、客服系統、統計系統和監控系統我們也都可以做為通用的遊戲服務，提供給各遊戲專案使用，從而實現遊戲業的SAAS平臺。
多維度架構
一套遊戲平臺面向不同的部門和人員，所以也需要從不同的維度考慮和構建，從而儘量滿足大部分人的需求和便利。
小結
本章內容較多，首先從DevOps的理論開始介紹了，什麼是DevOps，以及我們什麼需要它，然後再結合實際一步步地介紹了DevOps的落地實踐。而DevOps最終能被實現主要歸功於它擁有豐富的開源技術工作，所以我們又介紹了目前常用的DevOps技術棧，最後通過對遊戲行業的分析介紹，實現了遊戲服務的拆分，最終從遊戲系統構架層入手實現了DevOps在遊戲中的落地。謝謝大家的支援！！