大服務器架構討論

最近參加了一個大服務器架構討論活動, 記錄下心得 概述

遊戲客戶端採用Cocos2dx-Lua的純Lua編寫邏輯, 服務器採用Golang做爲開發語言

遊戲類型相似於COC,所以無需選服. 須要使用大服務器架構進行處理 數據庫

採用Mongodb作持久存儲, redis作跨服通訊數據交換

使用UCloud的雲技術, 省去了煩人的運維工做 通訊及協議

客戶端和服務器通信使用HTTP短鏈接, 基於json的數據封包協議

服務器間大量使用Golang自帶的json+rpc進行通訊 服務器類型

服務器類型大體分爲邏輯服務器,戰鬥服務器, 中心服務器 邏輯服務器

邏輯服務器負責平常邏輯及公共邏輯處理(好友, 公會)

1個邏輯服務器對應一個區, n個區均使用Ucloud雲Mongodb進行數據存儲 戰鬥服務器

戰鬥服務器是一個集羣, 集羣會返回一個負載最低的服務器返回使用

戰鬥服務器經過cgo技術與客戶端C++/lua的戰鬥邏輯進行邏輯複用, 在此技術上進行

戰鬥邏輯的校驗 中心服務器

客戶端登錄前, 在中心服務器這裏得到可登錄的邏輯服務器地址, 同時作一個負載均衡

短鏈接 評價

因爲操做系統的技術趨於穩定, 同時, 手遊的弱交互型致使的遊戲架構趨於簡單. 所以網絡負載再也不是遊戲服務器技術的瓶頸. 從經驗看來, 遊戲服務器技術, 更重要的是仍是看數據庫的選型及處理方式. 

雖然Mongodb的性能上不如內存數據庫. 可是從存儲安全性上要比我的搭建的內存數據庫簡單, 安全

外加上雲技術的引用, 性能的瓶頸和運維的技術複雜度迎刃而解

Redis用於跨服數據交互那是再好不過的數據中介了, 保證速度和穩定性, 絕對不是造輪子能比擬的

短鏈接在手游上處理起來比長鏈接簡單一些, 無需作斷線重連. 服務器的底層也是由Golang的框架庫保證質量的. 所以負載毫無問題. 服務器對內及對外均使用json進行數據交換, 簡化了協議處理. 也方便了調試

json rpc的性能損耗對於整個邏輯的處理來講都可以忽略不計