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

概述：本系列文章將從開發(fā)者角度梳理開發(fā)實時聯(lián)網(wǎng)游戲后臺服務(wù)過程中可能面臨的挑戰(zhàn)，并針對性地提供相應(yīng)解決思路，期望幫助開發(fā)者依據(jù)自身游戲特點(diǎn)做出合理的技術(shù)選型。

關(guān)于網(wǎng)絡(luò)游戲，維基百科給出的定義是：“通過計算機(jī)網(wǎng)絡(luò)，將專用服務(wù)器和用戶的客戶端設(shè)備(手機(jī)、PC、游戲主機(jī)等)相連，讓多名玩家同時聯(lián)機(jī)進(jìn)行游戲的娛樂形式?！庇纱丝芍W(wǎng)絡(luò)游戲涉及三個角色：客戶端、網(wǎng)絡(luò)、服務(wù)器，從網(wǎng)絡(luò)架構(gòu)上來講網(wǎng)絡(luò)游戲除了可分為C/S 架構(gòu)和P2P架構(gòu)(特指客戶端間直連通信)外，在實際開發(fā)中還有一種C/S和P2P架構(gòu)混合，即C/M架構(gòu)。

本系列文章主要討論C/M架構(gòu)。

C/M架構(gòu)與C/S架構(gòu)類似，和經(jīng)典的LAMP網(wǎng)站架構(gòu)類似一般C/S架構(gòu)的游戲后臺也可劃分為如下三層：（1）網(wǎng)絡(luò)接入層；（2）游戲邏輯層；（3） 數(shù)據(jù)存儲層。

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

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

根據(jù)OSI的七層網(wǎng)絡(luò)參考模型，我們可將網(wǎng)游網(wǎng)絡(luò)做如下7層劃分。

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

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

其原因有二：1、開發(fā)工作量大，質(zhì)量性能難以保證；2、平臺兼容性差(如H5并未提供socket編程能力)，而是基于更上層的通訊協(xié)議（如基于TCP的HTTP、Websocket協(xié)議，GRPC，以及基于UDP實現(xiàn)的QUIC，WebRTC協(xié)議等）。

值得注意的是，基于安全性考慮，瀏覽器標(biāo)準(zhǔn)未提供UDP收發(fā)能力，QUIC協(xié)議也只在chrome得到支持，WebRTC也還不是瀏覽器事實標(biāo)準(zhǔn)且協(xié)議初始目的用于實現(xiàn)點(diǎn)對點(diǎn)的音視頻通信，協(xié)議內(nèi)容過于龐雜不容易提煉應(yīng)用于游戲開發(fā)中，因而現(xiàn)階段H5游戲還只能采用HTTP或Websocket方式通訊。

通訊協(xié)議確定后，隨后要考慮的便是游戲?qū)ο蟮男蛄谢?/p>

序列化主要有基于文本、基于二進(jìn)制兩種，其優(yōu)劣如下表所示。在開發(fā)過程中一般會先采用文本序列化方式，便于前后端開發(fā)聯(lián)調(diào)，在游戲正式上線前切換至二進(jìn)制序列化方式以減少傳輸流量、提升編解碼效率。

至于數(shù)據(jù)安全性問題，為了保護(hù)敏感數(shù)據(jù)安全開發(fā)者可以選擇安全的https或WSS通訊協(xié)議，而對于直接基于TCP協(xié)議通訊，可采用先用RSA協(xié)商加密秘鑰，然后使用對稱加密方式將數(shù)據(jù)加密后發(fā)送。

通過以上分析，對于游戲協(xié)議類型的選擇我們給出以下準(zhǔn)則：

弱聯(lián)網(wǎng)類游戲

諸如休閑、卡牌類游戲可直接使用HTTP協(xié)議，對安全性有要求的話則使用HTTPS；

實時與交互性要求較高

這類游戲一般需要保持長連接，優(yōu)先選擇標(biāo)準(zhǔn)的ws協(xié)議（同時使用二進(jìn)制序列化方式），如考慮安全性可使用wss協(xié)議。而對于提供socket接口的native平臺也可使用TCP協(xié)議，同時對數(shù)據(jù)做對稱加密增強(qiáng)安全性；

實時性要求極高

不僅需要和服務(wù)器保持長連接，且延遲和網(wǎng)絡(luò)抖動都要求極高（如FPS，賽車類游戲），可使用基于UDP的實現(xiàn)流傳輸協(xié)議如QUIC，KCP等。

為了處理來自客戶端的并發(fā)請求，服務(wù)端有4種常見的并發(fā)模型。

進(jìn)程

典型：Apache

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

線程

典型：Tomcat

線程并發(fā)模型是進(jìn)程模型的改進(jìn)，線程從屬于進(jìn)程，是系統(tǒng)更小粒度的執(zhí)行調(diào)度單元。不同請求可由進(jìn)程內(nèi)多個并發(fā)執(zhí)行的線程來處理，這些線程由操作系統(tǒng)內(nèi)核自動調(diào)度。線程相對進(jìn)程的主要優(yōu)勢在于調(diào)度上下文切換開銷更小，但由于多個線程共享地址空間，需要額外的線程間互斥、同步機(jī)制來保證程序性正確性。

IO多路復(fù)用

典型：Nginx、netty

利用操作系統(tǒng)提供的epoll等IO多路復(fù)用機(jī)制，能同時監(jiān)控多個連接上讀、寫事件， IO多路復(fù)用也稱事件驅(qū)動模型，網(wǎng)絡(luò)程序執(zhí)行邏輯可抽象為事件驅(qū)動的狀態(tài)機(jī)。 IO多路復(fù)用避免了讀寫阻塞，減少了上下文切換，提升了CPU利用率和系統(tǒng)吞吐率。但I(xiàn)O多路復(fù)用它將原本“同步”、線性的處理邏輯變成事件驅(qū)動的狀態(tài)機(jī)，處理邏輯分散于大量的事件回調(diào)函數(shù)。這種異步、非線性的模型，極大地增加了編程難度，如nodeJs的常見的回調(diào)地獄問題。

協(xié)程

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

協(xié)程也稱輕量級線程，是一種協(xié)同、非搶占式的多任務(wù)并發(fā)模型。 協(xié)程運(yùn)行在用戶空間，當(dāng)遇到阻塞或特定入口時，通過顯式調(diào)用切換方法主動讓出CPU，由任務(wù)調(diào)度器選取另一個協(xié)程執(zhí)行。

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

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