實時聯網遊戲後臺服務技術選型和挑戰（網絡接入）
阿新 • • 發佈：2018-12-14
同時 混合 維基 指標 避免 秘鑰 原本 改進 擁有 述：本文嘗試從開發者角度梳理開發實時聯網遊戲後臺服務過程中可能面臨的挑戰，並針對性地提供相應解決思路，期望幫助開發者依據自身遊戲特點做出合理的技術選型。 維基百科關於網絡遊戲的定義：通過計算機網絡，將專用服務器和用戶的客戶端設備(手機、PC、遊戲主機等)相連，讓多名玩家同時聯機進行遊戲的娛樂形式，由此可知網絡遊戲涉及三個角色：客戶端、網絡、服務器，從網絡架構上來講網絡遊戲可分為C/S 架構和P2P架構(特指客戶端間直連通信)，在實際開發中還有一種C/S和P2P架構混合:C/M架構。
其中4層以下都由操作系統來負責，開發者無需為此操心，在實際的開發過程中開發者首要面臨的問題便是傳輸層是采用TCP還是UDP，下表簡要對比了兩者的優劣。 綜合兩者優劣，簡單來說除非對延遲有極致要求(例如FPS、MOBA類遊戲)需采用UDP外，TCP可應對大部分遊戲。
在實際遊戲開發中不管是采用TCP還是UDP方式，都較少利用通過Socket編程方式直接進行，一來因為開發工作量大，質量性能難以保證；二來平臺兼容性不好(比如H5並沒有提供socket編程能力)，而是基於更上層的通訊協議比如基於TCP的HTTP、Websocket協議，GRPC，以及基於UDP實現的QUIC，WebRTC協議等。
至於數據安全性問題，為了保護敏感數據安全開發者可以選擇安全的https或WSS通訊協議，而對於直接基於TCP協議通訊，可采用先用RSA協商加密秘鑰，然後使用對稱加密方式將數據加密後發送。
通過以上分析，對於遊戲協議類型的選擇我們給出有以下準則：
1、弱聯網類遊戲：諸如休閑、卡牌類遊戲可直接HTTP協議，對安全性有要求的話就使用HTTPS；
2、實時性，交互性要求較高：這類遊戲一般需要保持長連接，優先選擇標準的ws協議（同時使用二進制序列化方式），如考慮安全性可使用wss協議。而對於提供socket接口的native平臺也可使用TCP協議，同時對數據做對稱加密增強安全性；
3、實時性要求極高：不僅需要和服務器保持長連接，且延遲和網絡抖動都要求極高（如FPS，賽車類遊戲），可使用基於UDP的實現流傳輸協議如QUIC，KCP等。
2、並發模型
為了處理來自客戶端的並發請求，服務端有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
P2P架構不在本文討論範圍，C/M架構和C/S架構類似，和經典的LAMP網站架構類似一般C/S架構的遊戲後臺也可劃分為如下三層：（1）網絡接入層；（2）遊戲邏輯層；（3） 數據存儲層。
網絡接入、遊戲邏輯、數據存儲層各自所面臨的問題域及對應技術棧都大為不同，做此劃分不僅有助於模塊解耦、技術分工、組件復用，也可方便服務的運維部署。本文將著重先從網絡接入這個層面來闡述遊戲服務器的開發。 1、網絡接入層 網絡接入層的主要任務是建立客戶端和後臺服務以及客戶端之間的信道，接收來自客戶端大量並發請求，考核該層的主要性能指標是：高吞吐、低延遲。因而網絡接入層開發考驗的是開發者高性能網絡編程的功底，即解決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協議等。
至於數據安全性問題，為了保護敏感數據安全開發者可以選擇安全的https或WSS通訊協議，而對於直接基於TCP協議通訊，可采用先用RSA協商加密秘鑰，然後使用對稱加密方式將數據加密後發送。
通過以上分析，對於遊戲協議類型的選擇我們給出有以下準則：
1、弱聯網類遊戲：諸如休閑、卡牌類遊戲可直接HTTP協議，對安全性有要求的話就使用HTTPS；
2、實時性，交互性要求較高：這類遊戲一般需要保持長連接，優先選擇標準的ws協議（同時使用二進制序列化方式），如考慮安全性可使用wss協議。而對於提供socket接口的native平臺也可使用TCP協議，同時對數據做對稱加密增強安全性；
3、實時性要求極高：不僅需要和服務器保持長連接，且延遲和網絡抖動都要求極高（如FPS，賽車類遊戲），可使用基於UDP的實現流傳輸協議如QUIC，KCP等。
2、並發模型
為了處理來自客戶端的並發請求，服務端有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
實時聯網遊戲後臺服務技術選型和挑戰（網絡接入）