Discuz! 官方交流社區(qū)
標題: 游戲服務器架構通識 [打印本頁]
作者: dongbangyun 時間: 2025-7-31 11:39
標題: 游戲服務器架構通識
前言
這節(jié)講座里，我們將從游戲服務器發(fā)展的簡單歷程出發(fā)，鳥瞰一下目前大多數的游戲服務器架構。
這里盡可能的避免陷入細節(jié)的技術問題，而是從技術進化的結果狀態(tài)，反推原始問題是什么。希望能通過這個過程，解釋清楚游戲服務器是在解決什么問題，痛點到底在哪里。
一、早期網游服務器
蠻荒時期的游戲服務器框架我們一筆帶過，那時的游戲服務器和一個小Web服務沒有區(qū)別。
蠻荒時代的服務器只負責存儲玩家賬號、數據、轉發(fā)場景內其他玩家的行為。很多移動、使用技能等關鍵邏輯在服務器上根本沒有。隨意就能用變速齒輪改變游戲速度。
從《傳奇》的時代開始，游戲服務器就不再是簡單的上傳存檔、下載存檔、訪問頁面而已。游戲服務器內部出現了游戲邏輯，既能用于同步每個玩家看到的世界，又能讓邏輯與客戶端分離，避免早期的網絡游戲那種毫無防范的邏輯體系（對外掛防御能力為0）。
(, 下載次數: 4)
如圖，客戶端通過某種形式驗證登陸以后，就和服務器通過TCP直接相連了。這種服務器的承載能力不高，但那時在游戲邏輯上也務求簡化，把負載減少到極致。
· 例如：1、玩家看不到怪物的血量，或者只能看到正在打的怪物的血量。2、地圖有格子的概念，每個格子只能有一個單位，極大限制了同屏人數。
由于邏輯盡量簡化，雖然這時的服務器邏輯服務都是單進程單線程的，但是也足夠表現交互的感受。
這種架構奇怪的地方是處理網絡連接數據傳輸的壓力和邏輯處理的壓力在同一個服務器上（存儲模塊可能也在同一個進程），就算邏輯處理壓力為0，承載人數也高不到哪去。
雖然這時的游戲服務器設計很簡陋，但是網游第一次給了玩家真實世界的感受。單服人數不足的問題可以靠開多組服務器實現，所以曾經出現了幾百上千組服務器的輝煌時代。
二、早期游戲服務器的改進版本
當開發(fā)者們有了初步經驗以后，新作品的開發(fā)，自然而然的過渡到了如下的形式：
(, 下載次數: 5)
游戲邏輯服務依然是在一臺服務器上，單進程（邏輯處理本身肯定是在一個線程中，可以有子線程負責內網通信）。但是我們自然的想到，存儲負載和網絡連接負載可以從邏輯服上拆出來。
連接服務器負責把客戶端和服務器之間的消息轉化為服務器之間的消息，可以順便做一些加解密的工作。
這一點小改動極大提高了單服連接人數的上限。但是玩家要求提高了，空出來的性能很快被豐富的游戲系統(tǒng)吃掉了。
由于連接服務器本身沒有時序性，很容易做分布式的（其實大部分游戲還是只用一個連接服），存儲服務不要求高實時性，高峰期存盤間隔可以稍長一些，不會對游戲服造成影響。
三、成熟形態(tài)的服務器框架
邏輯服務器的負載均攤方法一：按照功能劃分多個服務器進程
(, 下載次數: 4)
邏輯服務器的負載均攤方法二：按照場景劃分多個服務器進程
對游戲服務器歷史有了基本了解后，成熟形態(tài)的游戲服務器很容易理解。簡單來說，就是把邏輯服務器單個進程的壓力分攤到多個服務器。
難點在邏輯的設計上，要像做手術一樣把本來是一體的功能切開，并抽象出若干個API來保持聯(lián)系（服務器之間是TCP連接）。
在分解時，要找聯(lián)系相對最薄弱的環(huán)節(jié)入手，比如場景和場景之間分開、單獨抽出聊天服務、組隊服務、好友服務。
無論如何分解，最終結果只能是有限個服務。而且分解的越細，開發(fā)難度就越大。因為跨服務器邏輯是把簡單的同步邏輯變成了異步Callback邏輯，而且容易出現時序問題等不易測試的問題。
單個場景服務幾乎是無法分解的。分解單個場景難度巨大以至于出現了BigWorld引擎來專門的解決場景分割問題，后面會談到。
(, 下載次數: 3)
這種成熟形態(tài)的游戲服務器已經能滿足現實中99%的頻繁交互類網游需求，是大型MMO端游、頁游的主流形式。
當然有實力的公司在這個基礎上會做很多改動，實現動態(tài)開辟副本、相位技術等等，但是萬變不離其宗，其本質和上圖沒有什么區(qū)別。
附：開房間式的網絡游戲
開房間式的網絡游戲也是游戲的一個重要分支，英雄聯(lián)盟、DOTA、很多手游例如皇室戰(zhàn)爭、王者榮耀等等。
這種游戲房間之間幾乎沒有交互，只有大廳內有交互，可以理解為原始形態(tài)的游戲服務器的平行擴展。
房間式游戲擴展難度較小，只是需要根據玩家數量動態(tài)擴展游戲房間的數量、服務器數量。很像網站的架構。
這種游戲架構最最適合放在云平臺上，設計合理的話，它可能遇到的問題和大型網站幾乎一模一樣。不需要特別的討論它們。
只是，畢竟游戲不都是開房間的玩法。
(, 下載次數: 3)
小結：游戲服務器框架特點
1、真正的數據都在內存中，數據庫性能不那么重要
· 注：很多大型游戲采用了共享內存，避免宕機時損失過大。
2、單CPU性能比CPU數量重要的多。
3、目前有很多游戲，特別是手游，使用Redis讀寫代替內存讀寫，甚至也有用Mongo的。
4、開新服、舊區(qū)合服的情況，非常適合云平臺。
五、先進服務器框架
· 先進服務器框架1 BigWorld
BigWorld引擎的代表作：
· 中國：《天下貳 》《天下叁》等等數十款，網易對BigWorld的實用化貢獻很大。
· 國際：《魔獸世界》早期版本，《坦克世界》，《戰(zhàn)爭雷霆》
BigWorld的核心理念，要回到上面講過的場景分割問題。
BigWorld利用平面切分的原理，將場景劃分為小塊，不同的塊可以運行在不同的服務器上。而且塊的劃分是動態(tài)的，根據玩家密集程度、數量動態(tài)調整塊的大小。。
具體技術上，使用了Actor模型，要求每個對象都是獨立的Entity，對象之間只能通過消息協(xié)作，嚴格限制對象之間的直接交互。
后來隨著手游的崛起、端游的衰落、網游玩法向多元化發(fā)展，這一系列的變化，導致BigWorld引擎很快就衰落了。
BigWorld引擎從曾經的大紅大紫，到現在的無人問津，反映出游戲服務器技術的發(fā)展趨勢。BigWorld的強制Actor模型，實際上是犧牲了開發(fā)效率，換取了服務器可擴展性。
理論上單服承載人數可以達到百萬級別。但是游戲的業(yè)務邏輯的修改很頻繁，開發(fā)效率低下是游戲設計師不能承受之重。
這種架構天生就是為云計算準備的，而且單個物理機承載量十分有限，每個游戲大區(qū)都需要大量實體機。
如果BigWorld成功…… 可惜的是，它和實際市場的發(fā)展趨勢背道而馳了。
游戲開發(fā)相比電商系統(tǒng)，項目規(guī)模小幾個數量級，但是相對的，迭代速度要快幾倍。項目之間如果類型不同或是玩法有差異，能復用的代碼并不多。
聊聊十萬行代碼。游戲服務器開發(fā)速度受美術資源制作速度、客戶端開發(fā)速度制約。近幾年我猜測服務器方面并不會有大的技術革新。
游戲開發(fā)未來的趨勢是多元化、低門檻化、大眾化。很長一段時間內BigWorld這種大怪獸級別的引擎不會再崛起。
分布式框架的崛起時間點，無論如何，也在VR技術成熟之后了。
· 先進服務器框架2、Skynet
Skynet是新興的一種通用型服務器框架（完全開源），它游走在傳統(tǒng)不易分布服務器和分布式服務器之間。
它是一種泛用型框架，不僅能很好的作為游戲服務器框架使用，而且用來搭建HTTP服務也具有驚人的性能（幾百行代碼的簡單HTTP實現，能達到nginx 60%的性能）。
矛盾的是，由于它對腳本虛擬機做了一些重要的Hack，導致它完全綁定在了Lua這一種語言上。
Skynet原理闡述：
把服務抽象為微服務，一個系統(tǒng)內可以建立成千上萬個微服務，Skynet調度m個線程（m=CPU核心數）、處理n個微服務各自的事件。
由于n個微服務在同一個進程內，可以達到0延遲的內部通信（極端情況下無拷貝）
同時Lua虛擬機又提供了沙盒機制，微服務之間的Lua邏輯代碼不會有任何干擾，必要的時候又可以在C語言層面、Lua沙盒之外共享數據。
由于服務本身有良好的隔離性，可以較為方便的把服務部署到多物理機上（考慮到性能問題，不能像BigWorld那樣任意部署）。
Skynet這種架構已經在Lua體系的游戲公司內大量使用（以網易系為代表），悄無聲息的滲透到其他公司里。（和Lua語言當年的情況有點像，是金子總會發(fā)光的。）
六、先進服務器框架3、以Go語言為主的其他框架
Go語言的goroutine特性，給游戲開發(fā)者帶來巨大的想象空間。
在Go語言的基礎上，很容易出現更好的房間式游戲框架、類似Skynet的框架、改進型的傳統(tǒng)框架。
但是可以大膽預測，最終實現的效果不會超過erlang、skynet這類框架的范圍。這是因為游戲業(yè)務本身的特性決定的。
結束語
本文簡要探討了十幾二十年來，主流服務器框架的發(fā)展脈絡，以MMO-RPG這種最具代表性的網游類型為主（同時MMO對服務器架構的挑戰(zhàn)也是最大的），兼談到一些其他類型的游戲。由于游戲類型多種多樣，各個國家和地區(qū)的開發(fā)商所偏好的架構方式也大有不同，文中難免掛一漏萬，但不太影響整體脈絡，也不影響對網游服務器的核心問題的總結——邏輯拆分。
| 歡迎光臨 Discuz! 官方交流社區(qū) (http://www.9999xn.com/) |
Powered by Discuz! W1.0 |