http://www.infoq.com/cn/articles/game-server-development-1
游戲服務器概述沒開發過游戲的人會覺得游戲服務器是很神秘的東西。但事實上它并不比web服務器復雜，無非是給客戶端提供網絡請求服務，本質上它只是基于長連接的socket服務器。當然在邏輯復雜性、消息量、實時性方面有更高的要求。
游戲服務器是復雜的socket服務器。
如果說web服務器的本質是http服務器，那么游戲服務器的本質就是socket服務器。 它利用socket通訊來實現服務器與客戶端之間的交互。事實上有不少游戲是直接基于原生socket來開發的。 相對于簡單的socket服務器，它承受著更加煩重的任務：
- 后端承載著極復雜的游戲邏輯。
- 網絡流量與消息量巨大，且實時性要求極高。
- 通常一臺socket服務器無法支撐復雜的游戲邏輯，因此在socket服務器的背后還有一個服務器群。
為什么純粹的socket服務器還不夠好？
很多web應用不會基于原生的http服務器搭建，一般都會基于某類應用服務器（如tomcat）搭建，而且還會利用一些開發框架來簡化web開發。 同樣，一般游戲服務器的開發都會在socket服務器上封裝出一套框架或類似的應用服務器。為什么使用原生的socket接口開發不夠好呢?
相關贊助商
QCon北京2016大會，4月21-23日，北京·國際會議中心，精彩內容邀您參與！
- 抽象程度。原生的socket抽象程度過低，接口過于底層，很多機制都需要自己封裝，如Session、filter、請求抽象、廣播等機制都要自已實現，工作量很大，容易出錯，且有很多的重復勞動。
- 可伸縮性。高可伸縮性需考慮很多問題，消息密度、存儲策略、進程架構等因素都需要考慮。用原生的socket要達到高可伸縮性，需要在架構上花費大量的功夫，而且效果也未必能達到開源框架的水準。
- 服務端的監控、管理。很多服務器的數據需要監控，例如消息密度、在線人數、機器壓力、網絡壓力等，如果采用原生socket，所有這些都要自己開發，代價很大。
用框架來簡化游戲服務器開發
一個好的框架可以大大簡化游戲服務器的工作。除了游戲自身的邏輯外，大部分的工作都可以用框架來解決。服務端的抽象，可伸縮性，可擴展性這些問題都可以通過框架來解決。 游戲服務器框架也承擔了應用服務器的功能。可以把框架看成容器，只要把符合容器標準的代碼扔進去，容器就運行起來了。它自然具備了抽象能力、可伸縮性和監控、管理等能力。
游戲服務器框架介紹
在開源社區里充斥了數不清的web服務器框架，游戲客戶端的框架和庫也有一大堆，但唯獨游戲服務器框架少之又少，零星有一些類庫，但完整的解決方案幾乎沒有。我們只好從商用的解決方案中拿出一些框架進行類比：
RedDwarf是唯一一個能找到的完整的開源游戲服務器框架，由sun出品。可惜在它合并到Oracle以后已經停止開發了。 在設計上，RedDwarf是個分布式架構，它在分布式數據存儲和任務管理上投入了太多精力，而且做的過于理想化，如動態任務遷移功能的實現非常復雜，但實際應用中根本用不到。而在可伸縮性和性能的設計上不太理想。因此RedDwarf夭折了。
SmartfoxServer是由意大利的一家游戲公司gotoAndPlay()推出的商用游戲服務器。 它是基于java開發的，與web應用服務器如Tomcat看上去很類似。Smartfox支持各種客戶端，且有一些成功案例。它在服務端封裝和監控管理方面實現得很完善。 但在可伸縮性上并不是太理想，盡管Smartfox也支持Cluster模式，但它的擴展方式是基于jvm內存復制的。也沒有實現傳統MMORPG基于場景分區的解決方案。 Smartfox有免費版本，但完全不開源。而且它的免費版本(達不到高并發用戶要求)很大程度是為了吸引開發者最終購買它的收費版本。不限在線人數的收費版本價格達到3500美刀。
Bigworld是澳大利亞Bigworld公司開發的全套3d MMORPG游戲解決方案，解決方案包含了客戶端和服務端。Bigworld功能非常強大，在動態負載均衡和容錯性做了很多工作。可擴展性非常強大。 它的缺點是過于重量級，對硬件要求高，且價格非常昂貴。Bigworld是專門為3d MMORPG游戲定制，但并不適用于中小型游戲的開發。
Pomelo是網易于2012年11月推出的開源游戲服務器。它是基于node.js開發的高性能、可伸縮、輕量級游戲服務器框架。 它的主要優勢有以下幾點：
- 開發模型快速、易上手，基于Convention over configuration的原則，讓代碼達到最大的簡化。
- 架構的可伸縮性和可擴展性好，pomelo在服務器擴展和應用擴展上實現得非常方便。
- 輕量級，雖然是分布式架構，但啟動非常迅速，占用資源少。
- 參考全面，框架不僅提供了完整的中英文檔，還提供了完整的MMO demo代碼(客戶端html5)，可以作為很好的開發參考。
Pomelo目前的主要缺點是推出時間尚短，一些功能還在完善中，支持的客戶端類型還有限，目前已支持HTML5、ios、android、untiy3d等4類客戶端，未來還會支持更多的客戶端類型。
游戲服務器的可伸縮性探討
不管是web應用還是游戲服務器，可伸縮性始終是最重要的指標，也是最棘手的問題，它涉及到系統運行架構的搭建，各種優化策略。 只有把可伸縮性設計好了，游戲的規模、同時在線人數、響應時間等參數才能得到保證。
為什么游戲服務器的可伸縮性遠遠不及web?
相比web應用幾乎無限擴展的架構（前提是架構設計得好），游戲服務器的可伸縮性相比就著差遠了。那么是哪些因素導致游戲無法達到web應用的擴展能力呢？ 說明：本文提到的web應用不包括類似于聊天這樣的高實時web應用，高實時web可認為是一種邏輯較簡單的游戲。
長連接和響應實時性
web應用都是基于request/response的短連接模式。占用的資源要比一直hold長連接的游戲服務器要少很多。Web應用能使用短連接模式的原因如下：
- 通訊的單向性，普通web應用一般只有拉模式
- 響應的實時性要求不高，一般web應用的響應時間在3秒以內都算響應比較及時的。
而游戲應用只能使用長連接，原因如下：
- 通訊的雙向性，游戲應用不僅僅是推拉模式，而且推送的數據量要遠遠大于拉的數據量
- 響應的實時性要求極高，一般游戲應用要求推送的消息實時反映，而實時響應的最大時間是100ms。
在高并發長連接服務的解決方案中，目前除了傳統的C語言（過于重量級）實現，用的最多的是erlang與node.js。兩者的性能指標差不多，而node.js在易用性方面毫無疑問勝出太多。
最近微博上看到時go的能撐起100萬的并發連接，node.js也能達到同樣的數據， Node.js w/1M concurrent connections!有node.js的長連接數據，它占用了16G內存，但CPU還遠沒跑滿。
交互的相鄰性與分區策略
普通的web應用在交互上沒有相鄰性的概念，所有用戶之間的交互都是平等，交互頻率也不受地域限制。 而游戲則不然，游戲交互跟玩家所在地圖（場景）上的位置關系非常大，如兩個玩家在相鄰的地方可以互相PK或組隊打怪。這種相鄰的交互頻率非常高，對實時性的要求也非常高，這就必須要求相鄰玩家在分布在同一個進程里。 于是就有了按場景分區的策略，如圖所示：
一個進程里可以有一個場景，也可以有多個場景。這種實現帶來了以下問題：
- 游戲的可伸縮性受到場景進程的限制，如果某個場景過于煩忙可能會把進程撐爆，也就把整個游戲撐爆。
- 場景服務器是有狀態的，每個用戶請求必須發回原來的場景服務器。服務器的有狀態帶來一系列的問題：場景進程的可伸縮，高可用性等都比不上web服務器。目前只能通過游戲服務器的隔離來緩解這些問題。
廣播
游戲中廣播的代價是非常大的。玩家的輸入與輸出是不對等的，玩家自己簡單地動一下，就需要將這個消息實時推送給所有看到這個玩家的其他玩家。 假如場景里面人較少，廣播發送的消息數還不多，但如果人數達到很密集的程度，則廣播的頻度將呈平方級增長。如圖所示：
假如場景中1000個玩家，每人發1條消息，如果需要其它玩家都看到的話，消息的推送量將高達1,000,000條，這足以把任何服務器撐爆。
解決這個問題的方案：
- 減少消息數量---消息只發送給能看到的玩家。玩家能看到的只是屏幕的大小，而不是整張地圖的大小，這樣推送消息的時候可以只推給對自己的狀態感興趣的玩家。這個可以用AOI（area of interested）算法來實現，在pomelo的庫pomelo-aoi中實現了簡單的燈塔算法。
- 分擔負載，將消息推送的進程與具體的邏輯進程分離。如圖：
這樣廣播邏輯與具體的進程邏輯就不會相互影響了，而且由于只有后端的場景服務器是有狀態的，前端負責廣播的服務器還是無狀態的，因此前端服務器可以無限擴展。
實時Tick
實時游戲的服務端一般都需要一個定時tick來執行定時任務，為了游戲的實時性，一般要求這個tick時間在100ms之內。這些任務包括以下邏輯:
- 遍歷場景中的實體(包括玩家、怪物等)，進行定時操作，如移動、復活、消失等邏輯。
- 定期補充場景中被殺掉的怪的數量。
- 定期執行AI操作，如怪物的攻擊、逃跑等邏輯。
由于實時100ms的限制，這個實時tick的執行時間必須要遠少于100ms，因此單進程內很多數據都會受到限制。
- 場景內實體的數量受限制，因為要遍歷所有實體
- 注意更新的算法，所有的算法，包括AI在內都要在幾十毫秒全部完成
- 注意GC，full GC最好永遠不要發生。一般full GC的時間都會高于100ms，幸好node.js在內存少于500M時表現良好，只有小GC。因此一定要控制內存大小。
- 盡量分進程，進程的粒度越少，出現tick超時或full GC的可能越少。在多核時代里，CPU是最廉價的資源。
高可伸縮的運行架構
經過以上這些分析。我們可以得到現在的運行架構，如下圖：
運行架構說明：
- 客戶端通過websocket長連接連到connector服務器群。
- connector負責承載連接，并把請求轉發到后端的服務器群。
- 后端的服務器群主要包括按場景分區的場景服務器(area)、聊天服務器(chat)和狀態服務器等(status)，這些服務器負責各自的業務邏輯。真實的案例中還會有各種其它類型的服務器。
- 后端服務器處理完邏輯后把結果返回給connector，再由connector廣播回給客戶端。 master負責統一管理這些服務器，包括各服務器的啟動、監控和關閉等功能。
這個運行架構符合了剛才提到的幾個伸縮性原則：
- 前后端進程分離，把承載連接和廣播的壓力盡量分出去。
- 進程的粒度盡量小，把功能細分到各個服務器
- 按場景分區
前面提到4個游戲服務器框架，只有bigworld和pomelo符合這樣的架構，當然bigworld實現的還要更復雜。 現在的問題是，這個運行架構是個分布式架構，而且并不簡單，那就帶來以下問題：
- 需要多少的代碼來實現這樣的運行架構？
- 服務器類型、數量管理和擴展有點復雜，該怎么管理？
- 服務器之間會有一堆的相互rpc調用，實現起來怎么簡化？
- 分布式的開發和調試并不容易，消耗資源量過大，過于重量級，多進程bug定位困難，該怎么解決？ Pomelo和node.js將很輕松地幫我們解決這些難題，我們下一節將討論。
node.js、pomelo與游戲服務器
Node.js的特點與游戲服務器極其符合。列舉如下:
- 對網絡IO的處理能力，node.js生來就是為IO而生的，而游戲服務器剛好是網絡密集型的應用。
- 單線程的應用模型，node.js的單線程處理能力遠比其它語言強大，而單線程處理游戲邏輯是最簡單，最不容易出錯，而且不可能出現死鎖、鎖競爭的情況。
- 語言與輕量的開發模型。Javascript語言已經不是昔日的吳下阿蒙，它不僅由于腳本語言的輕量、簡單帶來了開發效率的提升。還可以與一些類型的客戶端共享部分代碼，如html5，unity3d的js客戶端等。
- 語言的動態性帶來了很多框架設計的便利，如設計DSL，實現Convention over configuration。盡管這方面比ruby稍差，但在pomelo框架中使用已經足夠好了。
Pomelo是基于node.js搭建的游戲服務器框架，它在靈活性、擴展能力，輕量級調試方面具有無可比擬的優勢。我們先簡單回答第三章最末的幾個問題：
- 用pomelo來實現以上的運行架構幾乎是零代碼的，因為它在設計時天生就具備這樣的架構。
- 服務器類型、數量的管理極簡單，利用鴨子類型、目錄定義，只要一個簡單json配置文件就可以實現所有服務器的管理。
- rpc調用可以實現完全零配置，也不用生成stub。感謝js語言的動態性，基于Convention over configuration的原則，可以直接實現rpc調用。
- 分布式的開發和調試只占用很少的資源，啟動極其迅速，十幾個進程只用10秒不到的時間完全啟動。多進程調試與單進程調試沒有任何區別，只在一個console里搞定。
在本系列文章后面將會陸續討論pomelo是怎么實現以上如此方便的特性， 以及這些設計帶來的啟發。
小結
本文分析了游戲服務器框架的市場現狀，一個高可伸縮游戲服務器架構的設計原則及運行架構。Node.js與pomelo在解決高并發和分布式架構中起到的作用。下文我們將深入分析pomelo在解決復雜的游戲服務器運行架構中提供了哪些便利。
posted on 2016-03-14 09:12
思月行云 閱讀(461)
評論(0) 編輯 收藏 引用 所屬分類:
Node.js