最近參加了一個大服務器架構討論活動, 記錄下心得
概述
游戲客戶端采用Cocos2dx-Lua的純Lua編寫邏輯, 服務器采用Golang作為開發(fā)語言
游戲類型類似于COC,因此無需選服. 需要使用大服務器架構進行處理
數(shù)據(jù)庫
采用Mongodb做持久存儲, redis做跨服通信數(shù)據(jù)交換
使用UCloud的云技術, 省去了煩人的運維工作
通信及協(xié)議
客戶端和服務器通訊使用HTTP短連接, 基于json的數(shù)據(jù)封包協(xié)議
服務器間大量使用Golang自帶的json+rpc進行通信
服務器類型
服務器類型大致分為邏輯服務器,戰(zhàn)斗服務器, 中心服務器
邏輯服務器
邏輯服務器負責日常邏輯及公共邏輯處理(好友, 公會)
1個邏輯服務器對應一個區(qū), n個區(qū)均使用Ucloud云Mongodb進行數(shù)據(jù)存儲
戰(zhàn)斗服務器
戰(zhàn)斗服務器是一個集群, 集群會返回一個負載最低的服務器返回使用
戰(zhàn)斗服務器通過cgo技術與客戶端C++/lua的戰(zhàn)斗邏輯進行邏輯復用, 在此技術上進行
戰(zhàn)斗邏輯的校驗
中心服務器
客戶端登陸前, 在中心服務器這里獲得可登陸的邏輯服務器地址, 同時做一個負載均衡
短連接
評價
由于操作系統(tǒng)的技術趨于穩(wěn)定, 同時, 手游的弱交互型導致的游戲架構趨于簡單. 因此網(wǎng)絡負載不再是游戲服務器技術的瓶頸. 從經驗看來, 游戲服務器技術, 更重要的是還是看數(shù)據(jù)庫的選型及處理方式.
雖然Mongodb的性能上不如內存數(shù)據(jù)庫. 但是從存儲安全性上要比個人搭建的內存數(shù)據(jù)庫簡單, 安全
外加上云技術的引用, 性能的瓶頸和運維的技術復雜度迎刃而解
Redis用于跨服數(shù)據(jù)交互那是再好不過的數(shù)據(jù)中介了, 保證速度和穩(wěn)定性, 絕對不是造輪子能比擬的
短連接在手游上處理起來比長連接簡單一些, 無需做斷線重連. 服務器的底層也是由Golang的框架庫保證質量的. 因此負載毫無問題. 服務器對內及對外均使用json進行數(shù)據(jù)交換, 簡化了協(xié)議處理. 也方便了調試
json rpc的性能損耗對于整個邏輯的處理來說均可以忽略不計