以下比較的基礎都是基于一種編程語言+一定的第三方或者自己編寫的網絡庫和底層進行的，Skynet稍微特殊，但總體比較合適放到比較中來

C#

開發效率：Windows下可以通過VisualStudio進行開發，其他平臺可以使用MonoDevelop，非常方便

運行效率：JIT的性能優化比較到位，能適應90%性能環境

部署便捷性：可以通過交叉編譯生成其他平臺的可執行文件，通過mono運行可執行文件

調試便捷性：VisualStudio和MonoDevelop調試均很方便， 還可遠程調試

上手度：對C系語言熟悉的幾天就可上手

熱更新：可以通過DLL方式進行

Web對接：可做，代碼比較啰嗦

崩潰處理：可通過try catch捕獲錯誤

網絡庫編寫難度：一般，需注意gc問題

第三方網絡庫及框架數量：一般

Golang

開發效率：高

運行效率：并發上非常有優勢，對CPU利用率比較高，原生運行無虛擬機

部署便捷性：一次編譯到處運行，無任何運行庫依賴

調試便捷性：實際操作中，單線程掛接調試器可行， 但變量顯示不正確，開發期基本采用日志方式進行查錯

上手度：語言簡單，特性少， 新手1周能貢獻代碼

熱更新：無法進行熱更新，語言無法編譯為DLL，也不支持DLL加載（linux平臺的.so加載忽略不計）

Web對接：非常方便， 代碼精簡

崩潰處理：崩潰后以命令行方式打印出棧，程序內可以捕獲任何崩潰錯誤并繼續運行

網絡庫編寫難度：簡單，比C socket更簡單

第三方網絡庫及框架數量：偏少

Skynet(lua+C)

開發效率：基于動態語言的開發初次寫比較快，后期維護和重構會耗費一定的時間在查錯上

運行效率：基于lua jit的運行效率還是能接受的

部署便捷性：方便， 只有底層修改需要重新編譯， 大部分時間只用更新lua文件

調試便捷性：不是很方便，基于日志方式進行查錯

上手度：lua語言特性有部分和C系語言有一定差異，基于Actor模型的思想學習，適應需要耗費一定的時間

熱更新：類似于Erlang，可精確到函數級的熱更新

Web對接：有一些http支持，通過社區慢慢進行完善

崩潰處理：lua天生可以捕獲錯誤

網絡庫編寫難度：自帶，無需編寫

第三方網絡庫及框架數量：通過社區慢慢完善

C++

開發效率：編譯慢，文件多，通用庫少

運行效率：native速度標桿

部署便捷性：編寫各類的make門檻較高

調試便捷性：可通過VisualStudio進行Windows平臺調試

上手度：2~3年經驗的熟手仍然會寫出崩潰和泄露代碼

熱更新：可通過DLL進行

Web對接：代碼啰嗦，第三方庫少

崩潰處理：Windows下可使用SEH捕獲段異常，其他平臺只能通過崩潰后進行coredump分析，容錯非常差

網絡庫編寫難度：基于asio編寫較為簡單，但總體看來難度不低

第三方網絡庫及框架數量：較多

以下是得分

從發文時的項目對這些語言使用率來說，Java，Erlang，C++編寫的服務器較多，Golang，JavaScript，C#是第二梯隊，Skynet由于上手不是很容易，所以僅有兩位數的團隊在使用，但總體表現還是比較出色的

對于老團隊， C++的服務器工具鏈和框架已經相對成熟， 完全沒必要更換新語言， 只是在對接sdk感覺困難時，可以嘗試Golang這些對web有優勢的語言進行混合語言開發

對于新團隊，開發效率，上手度和部署效率是優先選擇的，C#，Golang，JavaScript這些新興語言會讓你事半功倍

對于大規模無需選服的服務器， Skynet的actor模型對擴展會比較容易

對于大公司，好項目，上線后需要通過熱更新進行bug修補的，C#，C++，Erlang會是首選

但總的一點， 還是根據團隊熟悉度來選擇語言，貿然的使用新語言的風險也是很大的

最近和團隊討論打包導致的發版本時間過長的問題: 平均1個小時

Unity3D現在官方不支持熱更新, 雖然有一些lua的熱更方案, 但鑒于項目開始時lua熱更還不成熟, 所有沒有采用

經過長時間業界和技術的摩擦, 渠道基本認同了Unity3D不能熱更的現實

根據我們這邊運營分析的熱更新的需求: 臨時關閉功能避免bug刷錢

在強力的QA支持(我們有)下, 可以保證版本的功能不會有明顯問題, 即便有問題, 可以通過服務器關閉功能達到效果

這樣來說, 代碼上的熱更新基本是不可能了, 只能通過服務器來配合, 所以我們只考慮資源熱更新需求.

場景: 這部分屬于PVE功能, 雖然包含有怪物擺放的邏輯, 但一般一旦做好基本沒有更新需要

角色: 后期這塊可能會考慮更新, 但明顯系統上可以同時支持打包和非打包需求, 因此默認包內的角色可以直接打包, 未來的付費相關的角色熱更新需求既可以通過

一階段打包更新, 也可以根據增量更新進行. 

界面: 知識更新界面包只能修改界面布局和坐標, 邏輯依然需要打包更新, 所以這塊完全有必要不做打包

特效: 特效與角色和界面關聯緊密, 而且混用, 交叉的情況很多, 打包明顯會造成一部分資源重復進入包體, 因此果斷不打包

總結下來, 資源的更新一定是伴隨著代碼的更新來做的, 那么可以規劃一個大版本, 把需要更新的資源和功能邏輯一塊更新

雖然大包更新會損失一定的用戶, 但未來在核心穩定的情況下, 可以考慮把新功能用腳本來更新

資源不打包帶來明顯的優勢: 資源加載變的更快了, 制作流程變的更簡單, 無需兼容打包和非打包情況. 包體大小有小幅度下降( 重復打包部分)

簡單,方便,高效的Go語言的游戲服務器框架

func server() {

    pipe := cellnet.NewEventPipe()

    evq := socket.NewAcceptor(pipe).Start("127.0.0.1:7234")

    socket.RegisterSessionMessage(evq, coredef.TestEchoACK{}, func(content interface{}, ses cellnet.Session) {

        msg := content.(*coredef.TestEchoACK)

        log.Println("server recv:", msg.String())

        ses.Send(&coredef.TestEchoACK{

            Content: proto.String(msg.String()),

        })

    })

    pipe.Start()

}

func client() {

    pipe := cellnet.NewEventPipe()

    evq := socket.NewConnector(pipe).Start("127.0.0.1:7234")

    socket.RegisterSessionMessage(evq, coredef.TestEchoACK{}, func(content interface{}, ses cellnet.Session) {

        msg := content.(*coredef.TestEchoACK)

        log.Println("client recv:", msg.String())

    })

    socket.RegisterSessionMessage(evq, coredef.SessionConnected{}, func(content interface{}, ses cellnet.Session) {

        ses.Send(&coredef.TestEchoACK{

            Content: proto.String("hello"),

        })

    })

    pipe.Start()

}

項目地址: https://github.com/davyxu/cellnet

與慕課網合作的視頻教程系列, 不定期更新, 按時間倒序排列

歡迎各位參觀, 學習

Cocos2d-x游戲開發入門－貪吃蛇

http://www.imooc.com/view/487

http://www.imooc.com/learn/508

Cocos2d-x游戲開發基礎之Lua基礎篇

http://www.imooc.com/view/485

Cocos2d-x初體驗之Lua篇

http://www.imooc.com/learn/448

最近接入pp助手的服務器端支付, 按照PP官方提供的文檔來看, 需要服務器做RSA的驗證.

首先我們來看下

RSA的幾個標準用法

非對稱加密解密

假設A要把內容傳輸給B

1. B生成RSA的公鑰和密鑰, 這是成對出現的, 密鑰由B保存, 把公鑰告訴A

2. A用B的公鑰加密內容, 并把密文內容傳輸給B

3. B用密鑰解密

驗證

證明某個內容是你發的, 而不是被別人冒名頂替, 例如git的push中就帶有這個功能

假設A有內容,  B要驗證內容確實由A發出

1. A生成公鑰和密鑰

2. A將內容做一個hash, 把hash碼用自己的密鑰加密并把這段密文發給B

3. B用A的公鑰對密文進行驗證, 即可確認密文是否由A發出

可以看出, 兩種用法都是典型的非對稱用法

但PP助手卻干了件神奇的事情:

非對稱當對稱算法加解密

在PP SDK官方文檔里, 我們找到了PHP語言的驗證方法, 方法里使用了這樣一個API

openssl_public_decrypt

從官方文檔看得出這個使用openssl的算法庫

類似的, 還有Java, C++, Python語言的處理方法

其中, C++也是用的openssl, Python則是需要預編譯C庫，在Ubuntu下需要手工patch M2Crypto的_ssl.c文件.

先不說這些非正規的編譯,patch方法會造成多大的問題, 單就這個用公鑰解密就很蛋疼

從之前的RSA算法中了解, 只有對公鑰進行驗證的方法, 也就是只能得到是還是不是的結果. 但PP的SDK則要求必須用公鑰解密…

解出的數據為一段json, 以對比是否有訂單篡改.

那么這種做法就等效于, 用最簡單的異或+一個公鑰進行訂單加密, 然后同樣用這個公鑰進行解密

只不過用RSA感覺很高級…

這種做法一旦公鑰在PP助手服務器或者玩家的開發服務器, 甚至源代碼泄露, 那么馬上就有很大的偽造訂單的危險

我把這個做法發給朋友看, 他們說, 其實PP助手的開發者只管用了RSA, 跟傳輸不是明文就好了, 至于什么信息安全, 都是屁!

看C#例子

            Action[] a = new Action[3];

            for (int i = 0; i < 3; i++)

            {

                a[i] = ( ) => { Console.WriteLine(i); };

            }

            for (int i = 0; i < 3; i++){

                a[i]();

            }

C#打印結果為3 3 3

Golang的例子

    a := make([]func(), 3 )

    for i := 0; i < 3; i++ {

        a[i]= func( ){

            fmt.Println(i)

        }    

    }

    for _, s := range a {

        s()

    }

Golang打印結果為3 3 3

最后是Lua的例子

a = {}

for i = 1, 3 do

    table.insert( a, function()

        print(i)

    end

    )

end

for _, v in ipairs(a) do

    v()

end

Lua打印結果為1 2 3

差異在于, C#和Golang將變量捕獲到閉包內時, 均使用引用方式, 即當最后開始調用使用變量時, 由于變量已經結束循環, 所以是最終值

但是Lua捕獲方式是值捕獲, 因此比較容易理解, 是多少就是多少

多線程+同步阻塞模型

在我們的游戲項目中使用的golang服務器開發方式如下

1.多線程邏輯

2.同步阻塞. 也就是說, 每個人一個線程(goroutine), io線程=邏輯線程

這種方式的優點:

1. 同步阻塞方式與人的思維方式類同

2. 邏輯處理性能有一定提升

在大規模使用這種模式編寫邏輯后, 我們發現了這種模式只有1個缺點: 編寫者需要處理多線程關系

但這本身確實直接致命的, 回想C++時代, 多線程處理時, 調試重現的困難… 腦補景象太慘不敢直視

單線程+異步多進程模型

在C++時代, 我曾經編寫過一套asio的C++服務器框架. 采用io多線程, 邏輯單線程, 依賴著C++高性能的優勢, 讓開發便捷簡單且無需關心線程問題.

那么到了golang時代, 為什么不能試下單線程異步多進程方式來編寫邏輯?

與多線程同步阻塞對比后, 我們發現, 兩者優缺點互補. 那這就回到了領域選型問題了. 對于游戲服務器需要的上手簡單, 開發便捷, 壓力降低(非MMO)這些特點來說, 單線程異步多進程再合適不過了

那么, 我們在用golang編寫單線程異步多進程服務器應該注意哪些點呢?

1. socket處理完全封裝, 只通過channel拋出到邏輯線程排隊處理

2. 數據庫, rpc及其他io處理, 一律改為異步回調模式, 不使用同步接口

3. 玩家存盤提交數據可以考慮復制并提交到存盤線程方式, 提高性能.

4. 采用多進程架構, 比如設網關進程, 把io壓力分散到進程中

5. 邏輯編寫中, 不允許使用go開線程及channel, 有需要提高性能部分需要單獨編寫

Actor模型的痛

cellnet在開發時本來考慮使用actor模型來進一步簡化多線程邏輯的麻煩, 經歷了一段時間的原型開發后, 發現了一些問題, 列舉如下:

1. golang的強類型不適合actor模型這種經常需要動態生成各類消息的模型, 但skynet(C+lua)/erlang就有天生優勢

2. actor模型本身不是萬能的, 不能解決所有需求, 特別是游戲

3. actor模型理解到應用有一定的難度. 本身還需要搭建框架, 上手復雜

總之, 看過一些erlang及skynet的用例, 沒有應用的很純正且成熟的成功actor模型案例, 從傳統socket服務器框架跨越到actor模型會扯到蛋, 因此, 后期cellnet會考慮回歸到成熟的socket服務器框架. 把架構做到簡單上手, 高擴展上.

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

概述

游戲客戶端采用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的性能損耗對于整個邏輯的處理來說均可以忽略不計

項目中, 我們使用Unity3D做客戶端開發. 自己擼了一套C#網絡庫, 隨著項目的推進, 問題來了:

問題

每次Unity3D編輯器打開時, 連接服務器都會有一定幾率失敗, 需要反復關閉再打開編輯器3~4次后, 才能正常接收到封包

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

探索

我們的網絡庫基于C#的Begin/End系的異步Socket, 這種socket更接近C++的asio模型, 擼起來特爽.

1. 根據經驗, 這個詭異問題多半跟多線程有關系. 復查代碼, 無效.

2. 找友人更換網絡庫, 換阻塞Socket實現和SocketAsyncEventArgs這種實現都試過, 仍然無法解決問題.

3. 接下來還是對Begin/End系的網絡庫進行日志追蹤. 發現, 發送會總是成功, 連接成功和接收封包有一定幾率會斷掉

我們并沒有單獨開線程來處理, 而是利用底層異步通知, 然后有線程安全隊列切換到主線程進行投遞. 因此底層的線程正常性是整個問題的焦點

由于一直無法找到原因, 這個問題擱置了

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

解決方案

直到有一個偶然的機會, 取過同事代碼后. 突然發現第一次打開Unity3D編輯器可以直接登錄. 但之后又不行. 同事提醒, 會不會是優先度問題.

馬上打開Edit->Project Settings->Script Execution Orders. 提高了網絡組建優先度

測試, 通過, 問題解決

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

總結

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

一直懷疑這個問題跟Mono版本過老有關系, 但由于5.2版本到年底才更新, 之前只能自己啃bug.

在這個問題發生后解決前, 我們還有一個相關見聞: 我們將網絡部分比較穩定的代碼拆分放到dll中, 通過Unity3D的機制進行加載

結果, 網絡無法初始化. 估計也是跟這個問題有關系

總之, 有類似問題時, 可以試用腳本執行順序大法進行嘗試

數據庫選擇歷程

我們的項目一直使用MySQL作為數據庫. 無論是從C++的服務器, 還是到Golang服務器. 當年搞服務器時, 看大部分人都是用SQL(MySQL/SQLServer), 而Mongo感覺像邪教一樣, 再加上服務器還是Linux比較正統, 所以果斷選了MySQL.

剛開始感覺,游戲服務器的數據存儲其實應該是蠻神圣的過程. 那么多的數據, 需要按照MySQL一樣分表, 分字段存儲, 為了查詢, 還要乖乖的學一下SQL的語法

就這么折騰了幾年. 在云DB的蒙蔽下, 一直認為MySQL就是做游戲服務器存儲的專業技術. 分布式和存儲壓力一定交給云DB來做. 直到真正試了下NoSQL在游戲服務器開發里的思路.

用了Golang, 才發現同步寫邏輯是多么的優雅.

用了NoSQL系列的數據庫, 才意識到: 游戲服務器的數據存儲和游戲服務器的存盤兩個概念差異其實蠻大的.

MySQL中, 背包其實跟角色完全沒有關系, 只是通過1個角色id映射過去, 人為的割裂了數據的關聯性. 還硬生生的整出個概念叫結構化查詢讓你學

NoSQL中, 只是把數據庫當成是存儲點, 每個角色的數據是完整的一塊. 里面怎么存隨你便. 每個角色通過id來查詢, 其他都沒有了

于是乎, 游戲開發變得異常簡單. MySQL角色進門查詢4~5次才能搞定要的數據.而NoSQL一口氣全查出來, 存盤也無需增量, 直接存盤就可以了

所以現在覺得, NoSQL的思路對于游戲服務器存儲來說簡直是完美的!

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

NoSQL數據庫方案對比

NoSQL下實現方案很多, 游戲常用的就這么3家: mongo, redis, memcached

下面說下優缺點

mongo

磁盤映射內存數據庫

value為document類型, 基于BSON的value序列化

應用場景:

適合多寫少讀, 例如日志和備份

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

redis

內存數據庫

單核

value限制512M

多種value類型, 游戲用途使用私有的序列化協議(例如protobuf)

支持落地(bgsave)

用戶: 新浪, 淘寶, Flickr, Github

應用場景: 適合讀寫都很高, 數據處理復雜等

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

memcached

內存數據庫

多核

value限制1M

不支持落地(持久化)

用戶: LiveJournal、hatena、Facebook、Vox

應用場景: 動態系統中的緩沖, 適合多讀少寫

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

個人評價

memcached 適合網頁緩沖, 游戲里很少有使用. 目前只有騰訊云支持云memcached

redis非常適合游戲的內存數據庫, 但是落地策略會比較復雜, 需要具體分析, 可以參考后面的鏈接看下云風怎么處理這個問題

mongo數據庫在早期還是非常不錯的NoSQL的數據庫. 工具比較方便, 可視化. 但是隨著近年來游戲的并發度越來越高, 所以為了一次到位, 很多人還是選擇了redis

下圖參考自知乎問題. 鏈接在后面有提示, 若侵權請聯系刪除

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

參考鏈接:

    談談陌陌爭霸在數據庫方面踩過的坑( Redis 篇)

http://blog.codingnow.com/2014/03/mmzb_redis.html

轉載請注明: 戰魂小筑http://www.shnenglu.com/sunicdavy

Memcache,Redis,MongoDB（數據緩存系統）方案對比與分析

http://blog.csdn.net/suifeng3051/article/details/23739295

http://www.zhihu.com/question/31417262