游戲服務器框架設計

Ø  序言

人們在認識事物的時候，一般都是先從大致的骨架開始，然后再到具體的細節，金字塔原理中用的比較多的就是自上而下的分析方法，這個方法放在放之四海而皆準。那么回到我們游戲服務器開發上面，也是如此。那么如何設計和選擇服務器架構以及有啥需要注意的呢？ 這是本文章要解決的問題。

文章主要目標人群是，對服務器框架設計感興趣，有從事過游戲框架設計的同學。

文章內容，介紹五大設計原則以及給出兩個示例,最后做總結。

Ø  設計原則

設計原則其實也是在設計時需要考慮的因素，過度設計是加重工作量的元兇，設計本質就是為了解決問題而存在的，下面列出了5大比較典型的原則。

1.         業務邏輯開發

a)         比如游戲為了增加存儲，你就需要考慮使用內存數據庫還是弄個數據庫網關服務器來處理。

b)         比如游戲為了管理游戲玩家賬號，以及支持對平臺賬號的接入，那么就需要賬號服務器。

c)         比如游戲為了管理游戲玩家訂單和跟蹤付費情況，可能就需要支付服務器，如果游戲類型是計時收費的話，那么可能會需要計時服務器。

2.         運營維護

a)         配置

這里牽涉到靜態配置和動態配置的問題，假設現在有一臺網關服務器和三臺游戲邏輯服務器，靜態配置的話，就是網關服務器這邊寫死只連接這三臺服務器，然后讓網關服務器主動去連接，動態配置的話，就是讓這三臺服務器知道這個網關服務器的地址，然后自己在啟動的時候去連接。

b)         開啟或者關閉順序

這主要是看各個服務器上面負責什么功能以及服務器上面的相關功能，拿游戲登陸服務器，游戲邏輯服以及數據庫網關服務器這三個服務器的架構來說，比如開啟的時候，你盡可能地跟玩家登陸連接的順序相反， 一般都是數據庫網關服務器，然后才是游戲邏輯服，最后才是游戲登陸服務器，其實就是防止玩家過早地登陸進來，卻發現數據還沒有準備好。

關閉的順序其實就是相反的，主要原則就是讓數據盡可能地保存好，并且讓玩家不再進來。

c)         動態增刪改

增刪改分為三部分：1）增加一臺服務器，2）減少一臺服務器，3）修改服務器信息，比如前面提到的靜態配置，就是不太方便增加服務器，要增加一臺服務器，需要更新網關服務器的配置表，然后讓網關服務器重新連接到新的服務器，而動態配置的話，就非常方便，讓新增的服務器發起到網關服務器就好了。無需更改配置。

d)         服務器管理

服務器的管理主要在服務器的在線離線狀態的管理，中心服務器（用來管理其它服務器）必須實時知道所管理服務器的狀態，比如網關服務器必須要實時知道游戲邏輯服的狀態，這樣才好更新到登陸服務器上面，更改服務器狀態。基本上在眾多同級服務器上面基本上都會有個中心服務器。

3.         性能效率

這需要權衡利弊和性能優劣，比如在ARPG游戲邏輯服務器里面大量的消耗在AI上面，那么就要考慮給弄個線程還是進程,這同樣適用于聊天功能，有一些聊天功能，或許可以選擇使用UDP來作為網絡層通訊方式。是否將功能模塊設計成單獨進程，這需要權衡，雖然可能在運營中會部署內網，相互之間是通過發消息的，類似于共享內存，但是還是會產生一些消耗的。

4.         負載均衡

這里包括兩個部分，硬件負載均衡，和軟件負載均衡。硬件負載均衡主要是指路由器。軟件負載均衡主要有幾種軟件,nginx/lvs/haproxy/dns, 負載均衡的策略，可以參考nginx 的負載均衡，主要有round-robin, least-connected, 以及ip-hash等。

一般來說，游戲中大都是二級負載，首先是在登陸這邊負載一次，然后再在進入游戲邏輯服那邊負載一次，這樣就夠了。

5.         安全性

這里說下網關服務器，其它地方也叫前置服務器，front-end servers,，這個有幾個好處：1）隱藏游戲邏輯服的連接信息. 2) 統籌游戲邏輯服的負載信息。

Ø  服務器框架示例

1)         無中心服務器架構

2)         有中心服務器架構

Ø  結論

服務器框架設計更像一門藝術，需要在解決問題的同時，又需要注意平衡得失。