遊戲伺服器架構通識

· 前言

· 我們將從遊戲伺服器發展的簡單歷程出發，鳥瞰一下目前大多數的遊戲伺服器架構

· 這裡儘可能的避免陷入細節的技術問題，而是從技術進化的結果狀態，反推原始問題是什麼。希望能通過這個過程，解釋清楚遊戲伺服器是在解決什麼問題，痛點到底在哪裡

· 一、早期網遊伺服器

· 蠻荒時期的遊戲伺服器框架我們一筆帶過，那時的遊戲伺服器和一個小Web服務沒有區別。

· 蠻荒時代的伺服器只負責儲存玩家賬號、資料、轉發場景內其他玩家的行為。很多移動、使用技能等關鍵邏輯在伺服器上根本沒有。隨意就能用變速齒輪改變遊戲速度。

· 從傳奇的時代開始，遊戲伺服器就不再是簡單的上傳存檔、下載存檔、訪問頁面而已。遊戲伺服器內部出現了遊戲邏輯，既能用於同步每個玩家看到的世界，又能讓邏輯與客戶端分離，避免早期的網路遊戲那種毫無防範的邏輯體系（對外掛防禦能力為0）。

· 這種架構奇怪的地方是處理網路連線資料傳輸的壓力和邏輯處理的壓力在同一個伺服器上（儲存模組可能也在同一個程序），就算邏輯處理壓力為0，承載人數也高不到哪去。

· 二、早期遊戲伺服器的改進版本

· 當開發者們有了初步經驗以後，新作品的開發，自然而然的過渡到了如下的形式：

· 遊戲邏輯服務依然是在一臺伺服器上，單程序（邏輯處理本身肯定是在一個執行緒中，可以有子執行緒負責內網通訊）。但是我們自然的想到，儲存負載和網路連線負載可以從邏輯服上拆出來。

· 由於連線伺服器本身沒有時序性，很容易做分散式的（其實大部分遊戲還是隻用一個連線服），儲存服務不要求高實時性，高峰期存檔間隔可以稍長一些，不會對遊戲服造成影響

·三、成熟形態的伺服器框架（這節是重點）

· 1、邏輯伺服器的負載均攤方法一：按照功能劃分多個伺服器程序

· 2、邏輯伺服器的負載均攤方法二：按照場景劃分多個伺服器程序

· 難點在邏輯的設計上，要像做手術一樣把本來是一體的功能切開，並抽象出若干個API來保持聯絡（伺服器之間是TCP連線）。

· 在分解時，要找聯絡相對最薄弱的環節入手，比如場景和場景之間分開、單獨抽出聊天服務、組隊服務、好友服務。

· 無論如何分解，最終結果只能是有限個服務。而且分解的越細，開發難度就越大。因為跨伺服器邏輯是把簡單的同步邏輯變成了非同步Callback邏輯，而且容易出現時序問題等不易測試的問題。

· 單個場景服務幾乎是無法分解的。分解單個場景難度巨大以至於出現了BigWorld引擎來專門的解決場景分割問題，後面會談到。

· 這種成熟形態的遊戲伺服器已經能滿足現實中99%的頻繁互動類網遊需求，是大型MMO端遊、頁遊的主流形式。

· 對比Web伺服器

大致只說一點：由於資料庫的存在以及HTTP請求的特性，Web伺服器天生就是併發的，也一直在高併發的路上越走越遠

· 附：開房間式的網路遊戲

· 開房間式的網路遊戲也是遊戲的一個重要分支，英雄聯盟、DOTA、很多手遊例如皇室戰爭、王者榮耀等等。

· 這種遊戲房間之間幾乎沒有互動，只有大廳內有互動，可以理解為原始形態的遊戲伺服器的平行擴充套件。

· 房間式遊戲擴充套件難度較小，只是需要根據玩家數量動態擴充套件遊戲房間的數量、伺服器數量。很像網站的架構。

· 這種遊戲架構最最適合放在雲平臺上，設計合理的話，它可能遇到的問題和大型網站幾乎一模一樣。不需要特別的討論它們。

· 只是，畢竟遊戲不都是開房間的玩法。

· 小結：遊戲伺服器框架特點

· 1、真正的資料都在記憶體中，資料庫效能不那麼重要

· 注：很多大型遊戲採用了共享記憶體，避免宕機時損失過大。

· 2、單CPU效能比CPU數量重要的多。

· 3、目前有很多遊戲，特別是手遊，使用Redis讀寫代替記憶體讀寫，甚至也有用Mongo的。

· 4、開新服、舊區合服的情況，非常適合雲平臺

· 先進伺服器框架

1、BigWorld。理念過於超前，把併發性做到極致，開發友好度弱到極致，已廢。

2、Skynet。本人強烈推薦，誰學誰知道，除了必須要用lua語言，沒有什麼缺點。

· 聊聊十萬行程式碼

· 遊戲伺服器開發速度受美術資源製作速度、客戶端開發速度制約。近幾年我猜測伺服器方面並不會有大的技術革新。

· 遊戲開發未來的趨勢是多元化、低門檻化、大眾化。很長一段時間內BigWorld這種大怪獸級別的引擎不會再崛起。

· 分散式框架的崛起時間點，無論如何，也在VR技術成熟之後了