遊戲開發之伺服器技術選型淺析

03-06

欲作此篇文章的想法由來已久，基本上，它是我因各種原因（被動）了解、接觸甚至使用了幾個市面上相對而言較有知名度的開源的遊戲伺服器框架後的總結和反思。

　　本文盡量客觀，但不可避免或會有不少帶個人偏好的觀點與看法；而限於個人目前的能力學識及眼界，本文所述內容或僅適於當前階段我的認知。

　　先擺個人觀點一：不推薦諸如 Pomelo 及 Skynet 等框架。

　　使用這類伺服器框架的原因，主要無外乎名氣大、能快速出活（有不少示例），但，事實真如此么？

　　這兩個框架無一例外，都是以腳本作為主要甚至唯一的開發語言（JavaScript、Lua），不可避免的，腳本語言的劣勢和短板在它們身上會被放大甚至大大放大，尤其當伺服器程序邏輯比較龐雜時/後。

　　靜態類型檢查、調試便利度（譬如 Skynet，調試？聊勝於無吧）、代碼可讀性、性能表現（譬如 Pomelo，其表現委實較差即便有 V8 加持）、維護重構成本（腳本一時爽XXXXX 當然只是調侃）...等等，這些都要審慎考慮。

　　本質上，動態腳本只是膠水語言（JavaScript、Python紛紛表示強烈反對，畢竟語言特性豐富且各類庫多如牛毛），或許，適度地在適合的場合適量地使用它們更符合它們的設計定位。而譬如 Skynet，雖然其宿主程序以 C 編寫，但在使用上，它「鼓勵」以 Lua 來編寫幾乎所有的邏輯，當然，譬如某些性能敏感的模塊等，可以 C/C++ 編寫動態庫供其調用——麻煩么？有點。

　　印象里在 Skynet 的 wiki 里看到其作者解釋為何 Skynet 官方版本不支持 Windows，大意是因 Windows 的網路性能不行——呵呵，這得有多大的並發多大的流量呢？IOCP 性能不行？。真考慮性能，哪還會如此重度的使用腳本？再考慮到可能大部分程序員的開發工作恐怕都在 Windows 下，需得先將腳本全部上傳至 Linux 後伺服器程序才能運行起來，不費時費事么？

　　Lua 在遊戲行業的普遍使用，恐怕或多或少有 WOW 這一鮮活案例的原因。而國內大量使用腳本編寫遊戲邏輯的開發模式，估計網易首創。slua 的作者說的好，「經過良好設計的遊戲引擎，都是思考過什麼應該引擎層做，什麼應該腳本化」——伺服器框架也同理。

　　我很難想像，譬如 WOW，若其伺服器代碼大部分甚至絕大部分模塊和邏輯都要以 Lua 編寫，該是怎樣的景象。

　　當然，如果只是練手或小遊戲等，拿這些框架來使無可厚非，順帶能學習下其設計什麼的——但恐怕也僅限如此了。譬如一些休閑類小遊戲，技術要求本來就不高甚至較低，與其去熟悉諸如 Pomelo 等「較重」的框架，多研究多參考自己寫一套也並非什麼難事，且更可控可定製，也更能提升水平經驗。

　　至於稍微上規模或較複雜的遊戲，幾乎可以肯定，基本不大會使用這些伺服器框架——譬如市面上熱門或較有知名度的遊戲，哪個使用了這些伺服器框架？譬如各類大小遊戲公司，有哪幾家在用這些伺服器框架？恩，Skynet 作者自己的公司在用，似乎暢遊貌似在嘗試 Pomelo（雖然網易自己都不用，其有自己的 MobileServer 引擎）。

　　基本上，正在使用或使用過這些遊戲伺服器框架的，幾乎都是沒什麼技術積累、技術水平還較一般的小公司小團隊。譬如騰訊等，技術積累深厚，人才多，耍的是 C++ + Lua 之類。

　　或許，若日常工作主要都是擼腳本（譬如 Lua），對個人的成長影響是較負面的，即便只是螺絲釘，也不應僅局限於此。

　　再擺個人觀點二：除卻 C++，Go 是開發後台程序的利器。

　　當然還有 Java，雖然重了些，但畢竟資源多、人才大把，後端技術棧基於之斷不失是個較實用的選擇。

　　而 C++，恐怕在技術積累和人才都不是問題的前提下才是較好的選擇，而似乎可以斷定的是，恐怕相當部分的小團隊甚至中小團隊等，都不太具備這個能力。C++ 本身的複雜度、開發效率甚至靠譜的可選人才等，都是相當現實的問題。

　　綜合這些因素等，或許可以嘗試基於 Golang 建立後端技術棧：學習成本低、使用已不可謂不廣、業界及遊戲界早已在用且不乏成功案例（BAT、TMD、巨人、游族等等）、大腿粗（Google 家出的且其內部使用較普遍，爹又是當初搞 C、Unix、UTF-8 等的那幫人）。

　　基本上，有些編程底子的技術人員，能較快地了解熟悉它，並能在較短時間內上手寫碼——當然，這個是要看人的。

　　而 Go 自身的語言設計也比較適合開發後台程序，開源及參考資料也較多，調試分發也很方便，等等。

　　應該是我水平差眼界低吧，我很難理解譬如雲風為何偏執於 Lua，可能大牛站得高想得多吧。

　　而我也只是「不推薦使用這些伺服器框架」而已，它們拓寬了遊戲伺服器的技術選型面，或多或少也是優秀的參考學習資源，從這些方面看，它們都是有實用價值的開源項目。

　　遊戲伺服器不可避免的會有類似「熱更」之類需求（所以才會是 C++ + Lua，而非只是 C++），配置類的熱更當然沒啥好討論的，至於邏輯代碼的修補熱更，譬如 Go，若習慣與 Lua 腳本交互的方式，成熟的參考當然有，如這個。

　　記得去年初我在搞基於 xLua 的客戶端熱更框架時，很贊同其作者的「若非熱更新之故，恐怕是沒多少人喜歡使用腳本的」之論斷，C# 多強大，Lua 好蛋疼...當然如寫習慣了，也湊合吧。畢竟，腳本有腳本的用武之地，作為技術人員，在合適的場合適度使用腳本即可，僅此而已。