游戲服務器的常用架構

@[toc]

讓我來學習一下。

背景

（專業，從背景出發）

游戲服務器，是一個會長期運行程序，并且它還要服務于多個不定時，不定點的網絡請求。所以這類服務的特點是要特別關注穩定性和性能。這類程序如果需要多個協作來提高承載能力，則還要關注部署和擴容的便利性；同時，還需要考慮如何實現某種程度容災需求。由于多進程協同工作，也帶來了開發的復雜度，這也是需要關注的問題。

游戲服務器架構要素

對于游戲服務端架構，最重要的三個部分就是，如何使用CPU、內存、網卡的設計：

內存架構：主要決定服務器如何使用內存，以最大化利用服務器端內存來提高承載量，降低服務延遲。

邏輯架構：設計如何使用進程、線程、協程這些對于CPU調度的方案。選擇同步、異步等不同的編程模型，以提高服務器的穩定性和承載量。可以分區分服，也可以采用世界服的方式，將相同功能模塊劃分到不同的服務器來處理。

通信模式：決定使用何種方式通訊。基于游戲類型不同采用不同的通信模式，比如http,tcp,udp等。

游戲類型

卡牌跑酷等休閑游戲弱交互游戲

分區分服RPG游戲（RPG頁游）

分服模型是游戲服務器中最典型，也是歷久最悠久的模型。在早期服務器的承載量達到上限的時候，游戲開發者就通過架設更多的服務器來解決。這樣提供了很多個游戲的“平行世界”，讓游戲中的人人之間的比較，產生了更多的空間。其特征是游戲服務器是一個個單獨的世界。每個服務器的帳號是獨立的，每臺服務器用戶的狀態都是不一樣的，一個服就是一個世界，大家各不牽扯。

后來游戲玩家呼吁要跨服打架，于是就出現了跨服戰，再加上隨著游戲的運行，單個服務器的游戲活躍玩家越來越少，所以后期就有了服務器的合并以及遷移，慢慢的以服務器的開放、合并形成了一套成熟的運營手段。目前多數游戲還采用分服的結構來架設服務器，多數頁游還是采用這種模式。

數據共享游戲服務器

網關部分分離成單端的gate服務器，DB部分分離為DB服務器，把網絡功能單獨提取出來，讓用戶統一去連接一個網關服務器，再有網關服務器轉發數據到后端游戲服務器。而游戲服務器之間數據交換也統一連接到網管進行交換。所有有DB交互的，都連接到DB服務器來代理處理。

場景服務器：它負責完成主要的游戲邏輯，這些邏輯包括：角色在游戲場景中的進入與退出、角色的行走與跑動、角色戰斗（包括打怪）、任務的認領等。場景服務器設計的好壞是整個游戲世界服務器性能差異的主要體現，它的設計難度不僅僅在于通信模型方面，更主要的是整個服務器的體系架構和同步機制的設計。

非場景服務器：它主要負責完成與游戲場景不相關的游戲邏輯，這些邏輯不依靠游戲的地圖系統也能正常進行，比如公會聊天或世界聊天，之所以把它從場景服務器中獨立出來，是為了節省場景服務器的CPU和帶寬資源，讓場景服務器能夠盡可能快地處理那些對游戲流暢性影響較大的游戲邏輯。

網關服務器: 在類型一種的架構中，玩家在多個地圖跳轉或者場景切換的時候采用跳轉的模式，以此進行跳轉不同的服務器。還有一種方式是把這些服務器的節點都通過網關服務器管理，玩家和網關服務器交互，每個場景或者服務器切換的時候，也有網關服務器統一來交換數據，如此玩家操作會比較流暢。

房間游戲

房間類玩法和MMORPG有很大的不同，在于其在線廣播單元的不確定性和廣播數量很小。而且需要匹配一臺房間服務器讓少數人進入一個服務器。

這一類游戲最重要的是其“游戲大廳”的承載量，每個“游戲房間”受邏輯所限，需要維持和廣播的玩家數據是有限的，但是“游戲大廳”需要維持相當高的在線用戶數，所以一般來說，這種游戲還是需要做“分服”的。典型的游戲就是《英雄聯盟》這一類游戲了。而“游戲大廳”里面最有挑戰性的任務，就是“自動匹配”玩家進入一個“游戲房間”，這需要對所有在線玩家做搜索和過濾。

玩家先登錄“大廳服務器”，然后選擇組隊游戲的功能，服務器會通知參與的所有游戲客戶端，新開一條連接到房間服務器上，這樣所有參與的用戶就能在房間服務器里進行游戲交互了。

（其實我覺得一個服務器里能扛得住不少房間吧，把房間號配置一下的話，不是不行呀）

5G游戲 NAT

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。