實時聯網遊戲後臺服務技術選型和挑戰（網絡接入）

述：本文嘗試從開發者角度梳理開發實時聯網遊戲後臺服務過程當中可能面臨的挑戰，並針對性地提供相應解決思路，指望幫助開發者依據自身遊戲特色作出合理的技術選型。 維基百科關於網絡遊戲的定義：經過計算機網絡，將專用服務器和用戶的客戶端設備(手機、PC、遊戲主機等)相連，讓多名玩家同時聯機進行遊戲的娛樂形式，由此可知網絡遊戲涉及三個角色：客戶端、網絡、服務器，從網絡架構上來說網絡遊戲可分爲C/S 架構和P2P架構(特指客戶端間直連通訊)，在實際開發中還有一種C/S和P2P架構混合:C/M架構。

 

 

P2P架構不在本文討論範圍，C/M架構和C/S架構相似，和經典的LAMP網站架構相似通常C/S架構的遊戲後臺也可劃分爲以下三層：（1）網絡接入層；（2）遊戲邏輯層；（3） 數據存儲層。

 

 

網絡接入、遊戲邏輯、數據存儲層各自所面臨的問題域及對應技術棧都大爲不一樣，作此劃分不只有助於模塊解耦、技術分工、組件複用，也可方便服務的運維部署。本文將着重先從網絡接入這個層面來闡述遊戲服務器的開發。

 

一、網絡接入層

網絡接入層的主要任務是創建客戶端和後臺服務以及客戶端之間的信道，接收來自客戶端大量併發請求，考覈該層的主要性能指標是：高吞吐、低延遲。於是網絡接入層開發考驗的是開發者高性能網絡編程的功底，即解決C10K甚至C10M的能力。

 

1.1協議選擇

根據OSI的七層網絡參考模型，咱們可將網遊網絡也作以下7層劃分:

 

 

其中4層如下都由操做系統來負責，開發者無需爲此操心，在實際的開發過程當中開發者首要面臨的問題即是傳輸層是採用TCP仍是UDP，下表簡要對比了二者的優劣。 綜合二者優劣，簡單來講除非對延遲有極致要求(例如FPS、MOBA類遊戲)需採用UDP外，TCP可應對大部分遊戲。

 

在實際遊戲開發中不論是採用TCP仍是UDP方式，都較少利用經過Socket編程方式直接進行，一來由於開發工做量大，質量性能難以保證；二來平臺兼容性很差(好比H5並無提供socket編程能力)，而是基於更上層的通信協議好比基於TCP的HTTP、Websocket協議，GRPC，以及基於UDP實現的QUIC，WebRTC協議等。

 

 

值得注意的是基於安全性考慮，瀏覽器標準未提供UDP收發能力，QUIC協議也只在chrome獲得了支持，WebRTC也還不是瀏覽器事實標準且協議初始目的是用於實現點對點的音視頻通訊，協議內容過於龐雜不容易提煉應用於遊戲開發中，於是現階段H5遊戲還只能採用HTTP或Websocket方式通信。

 

通信協議肯定後，隨後要考慮的即是遊戲對象的序列化，序列化主要有基於文本、基於二進制兩種，其優劣以下表所示。在開發過程當中通常會先採用文本序列化方式，便於先後端開發聯調，在遊戲正式上線前切換至二進制序列化方式以減小傳輸流量、提高編解碼效率。

 

 

至於數據安全性問題，爲了保護敏感數據安全開發者能夠選擇安全的https或WSS通信協議，而對於直接基於TCP協議通信，可採用先用RSA協商加密祕鑰，而後使用對稱加密方式將數據加密後發送。

 

經過以上分析，對於遊戲協議類型的選擇咱們給出有如下準則：

 

一、弱聯網類遊戲：諸如休閒、卡牌類遊戲可直接HTTP協議，對安全性有要求的話就使用HTTPS；

 

二、實時性，交互性要求較高：這類遊戲通常須要保持長鏈接，優先選擇標準的ws協議（同時使用二進制序列化方式），如考慮安全性可以使用wss協議。而對於提供socket接口的native平臺也可以使用TCP協議，同時對數據作對稱加密加強安全性；

 

三、實時性要求極高：不只須要和服務器保持長鏈接，且延遲和網絡抖動都要求極高（如FPS，賽車類遊戲），可以使用基於UDP的實現流傳輸協議如QUIC，KCP等。

 

二、併發模型

爲了處理來自客戶端的併發請求，服務端有4種常見的併發模型。

 

2.1進程

進程是最先採用的併發模型，進程做爲操做資源分配、調度的單位，擁有獨立的運行空間。進程併發模型中每一個請求由獨立的進程來處理，進程一次只能處理一個請求，該模型最大的優勢就是簡單。若是處理請求的進程因爲系統調用而阻塞或進程的時間片用完，搶佔式的進程調度器就會暫停舊進程執行，調度執行新的進程，這個過程涉及大開銷的上下文切換，進程併發模型的缺點是比較低效。最典型的採用進程模型的服務有Apache。

 

2.2線程

線程併發模型是進程模型的改進，線程從屬於進程，是系統更小粒度的執行調度單元。不一樣請求可由進程內多個併發執行的線程來處理，這些線程由操做系統內核自動調度。線程相對進程的主要優點在於，調度上下文切換開銷更小，但因爲多個線程共享地址空間，須要額外的線程間互斥、同步機制來保證程序性正確性。典型的採用線程模型的服務有Tomcat。

 

2.3 IO多路複用

利用操做系統提供的epoll等IO多路複用機制，能同時監控多個鏈接上讀、寫事件， IO多路複用也稱事件驅動模型，網絡程序執行邏輯可抽象爲事件驅動的狀態機。 IO多路複用避免了讀寫阻塞，減小了上下文切換，提高了CPU利用率和系統吞吐率。但IO多路複用它將本來「同步」、線性的處理邏輯變成事件驅動的狀態機，處理邏輯分散於大量的事件回調函數。這種異步、非線性的模型，極大地增長了編程難度，如nodeJs的常見的回調地獄問題。典型的採用IO複用模型的服務有Nginx，netty。

 

2.4 協程

協程也稱爲輕量級線程，是一種協同的、非搶佔式的多任務併發模型。 協程運行在用戶空間，當遇到阻塞或特定入口時，經過顯式調用切換方法主動讓出CPU，由任務調度器選取另外一個協程執行。

協程切換隻是簡單地改變執行函數棧，不涉及內核態與用戶態轉化，也涉及上下文切換，開銷遠小於進程/線程切換。協程的概念雖早已提出，隨着近些年年愈來愈多的語言（go、 Haskell）內置對協程支持才被開發者所熟知，協程極大的優化了開發者編程體驗，在同步、順序編程風格能快速實現程序邏輯，還擁有IO多路複用異步編程的性能。典型的採用協程模型的服務有openresty(Lua), gevent(Python), golang。

以上總結了目前4種經常使用的併發模型，它們在工做原理、運行效率、編程難度等方面有顯著區別，各自有適用場景，在實際使用時應該根據需求仔細評估。在實際開發過程當中若是沒有可複用的現成網絡組件或歷史包袱咱們建議使用協程併發模式開發網絡接入層服務。

 

轉自：http://gad.qq.com/article/detail/270717