摘要：概述本系列文章將從開發者角度梳理開發實時聯網游戲后臺服務過程中可能面臨的挑戰，并針對性地提供相應解決思路，期望幫助開發者依據自身游戲特點做出合理的技術選型。多路復用避免了讀寫阻塞，減少了上下文切換，提升了利用率和系統吞吐率。

概述：本系列文章將從開發者角度梳理開發實時聯網游戲后臺服務過程中可能面臨的挑戰，并針對性地提供相應解決思路，期望幫助開發者依據自身游戲特點做出合理的技術選型。

關于網絡游戲，維基百科給出的定義是：“通過計算機網絡，將專用服務器和用戶的客戶端設備(手機、PC、游戲主機等)相連，讓多名玩家同時聯機進行游戲的娛樂形式。”由此可知網絡游戲涉及三個角色：客戶端、網絡、服務器，從網絡架構上來講網絡游戲除了可分為C/S 架構和P2P架構(特指客戶端間直連通信)外，在實際開發中還有一種C/S和P2P架構混合，即C/M架構。

本系列文章主要討論C/M架構。

C/M架構與C/S架構類似，和經典的LAMP網站架構類似一般C/S架構的游戲后臺也可劃分為如下三層：（1）網絡接入層；（2）游戲邏輯層；（3） 數據存儲層。

網絡接入、游戲邏輯、數據存儲層各自所面臨的問題域及對應技術棧都大為不同，做此劃分不僅有助于模塊解耦、技術分工、組件復用，也可方便服務的運維部署。因此我們也會從這三個方面來闡述游戲服務器的開發。

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

根據OSI的七層網絡參考模型，我們可將網游網絡做如下7層劃分。

其中，4層以下都由操作系統來負責，開發者無需為此操心。而在實際開發過程中開發者首要面臨的便是傳輸層選擇TCP還是UDP的問題，兩者的優劣簡要對比參見下表。

綜合兩者優劣，簡單來說除非對延遲有極致要求(如FPS、MOBA類游戲)需采用UDP外，TCP可應對大部分游戲。在實際游戲開發中不管是采用TCP還是UDP方式，都很少直接通過Socket編程方式來進行。

其原因有二：1、開發工作量大，質量性能難以保證；2、平臺兼容性差(如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種常見的并發模型。

進程

典型：Apache

進程是最早采用的并發模型，進程作為操作資源分配、調度的單位，擁有獨立的運行空間。進程并發模型中每個請求由獨立的進程來處理，進程一次只能處理一個請求，該模型最大的優點就是簡單。如果處理請求的進程由于系統調用而阻塞或進程的時間片用完，搶占式的進程調度器就會暫停舊進程執行，調度執行新的進程，這個過程涉及大開銷的上下文切換。進程并發模型的缺點是比較低效。

線程

典型：Tomcat

線程并發模型是進程模型的改進，線程從屬于進程，是系統更小粒度的執行調度單元。不同請求可由進程內多個并發執行的線程來處理，這些線程由操作系統內核自動調度。線程相對進程的主要優勢在于調度上下文切換開銷更小，但由于多個線程共享地址空間，需要額外的線程間互斥、同步機制來保證程序性正確性。

IO多路復用

典型：Nginx、netty

利用操作系統提供的epoll等IO多路復用機制，能同時監控多個連接上讀、寫事件， IO多路復用也稱事件驅動模型，網絡程序執行邏輯可抽象為事件驅動的狀態機。 IO多路復用避免了讀寫阻塞，減少了上下文切換，提升了CPU利用率和系統吞吐率。但IO多路復用它將原本“同步”、線性的處理邏輯變成事件驅動的狀態機，處理邏輯分散于大量的事件回調函數。這種異步、非線性的模型，極大地增加了編程難度，如nodeJs的常見的回調地獄問題。

協程

典型：openresty(Lua)、 gevent(Python、golang。

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

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

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