如何看待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 可以用一個公式表達：

文化觀念的改變 + 自動化工具 = 不斷適應快速變化的市場

其核心價值在于以下兩點：

1. 更快速地交付, 響應市場的變化。

2. 更多地關注業務的改進與提升。

當理解了什么是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）手冊中的精益小屋：

而精益軟件開發是精益生產和實踐在軟件開發領域的應用，總結為如下七條原則：

1. 消除浪費

2. 增強學習

3. 盡量延遲決定

4. 盡快發布

5. 下放權力

6. 嵌入質量

7. 全局優化

精益管理貫穿于整個DevOps階段，它鼓勵主動發現問題，不斷的優化流程，從而達到持續交付、快速反饋、降低風險和保障質量的目的。接下來讓我們看看DevOps具體的實現方法。

實施DevOps的具體方法

• 建立快速敏捷團隊

  根據之前介紹的康威定律，我們可以看下目前公司中的項目團隊結構是怎么的，如下圖所示：

  

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

那么如何調整組織結構，建立一個Scrum團隊呢？（什么是Scrum請參考維基百科）

我們會按照業務功能劃分團隊，建立溝通群組，設置產品負責人（一個策劃人員）、Scrum Master（我們一般選擇測試人員擔任，測試驅動開發模式）和開發者團隊（前端工程師、后端工程師、測試各一名），最后的組織結構和系統架構如下圖所示：

一個高效的敏捷團隊是DevOps能落地的保障，那么自動化流程就是保證產品快速交付和持續部署的有效機制，接下來為大家介紹我們是如何實現自動化流程的？

• 實現自動化的流程

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

  

1. 提交：工程師將代碼在本地測試后，提交到版本控制系統，如 Git代碼倉庫中。

2. 構建：持續整合系統（如Jenkins CI），在檢測到版本控制系統更新時，便自動從Git代碼倉庫里拉取最新的代碼，進行編譯、構建。

3. 單元測試：Jenkins完成編譯構建后，會自動執行指定的單元測試代碼。

4. 部署到測試環境：在完成單元測試后，Jenkins可以將應用程序部署到與生產環境相近的測試環境中進行測試。

5. 預生產環境測試：在預生產測試環境里，可以進行一些最后的自動化測試，例如使用Appium自動化測試工具進行測試，以及與實際情況類似的一些測試可由開發人員或客戶人員手動進行測試。

6. 部署到生產環境：通過所有測試后，便可以使用灰度更新將最新的版本部署到實際生產環境里。

而實現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了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。