• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            戰(zhàn)魂小筑

            討論群:309800774 知乎關(guān)注:http://zhihu.com/people/sunicdavy 開源項(xiàng)目:https://github.com/davyxu

               :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              257 隨筆 :: 0 文章 :: 506 評論 :: 0 Trackbacks

            最近參加了一個(gè)大服務(wù)器架構(gòu)討論活動, 記錄下心得

            概述

            游戲客戶端采用Cocos2dx-Lua的純Lua編寫邏輯, 服務(wù)器采用Golang作為開發(fā)語言

            游戲類型類似于COC,因此無需選服. 需要使用大服務(wù)器架構(gòu)進(jìn)行處理

            數(shù)據(jù)庫

            采用Mongodb做持久存儲, redis做跨服通信數(shù)據(jù)交換

            使用UCloud的云技術(shù), 省去了煩人的運(yùn)維工作

            通信及協(xié)議

            客戶端和服務(wù)器通訊使用HTTP短連接, 基于json的數(shù)據(jù)封包協(xié)議

            服務(wù)器間大量使用Golang自帶的json+rpc進(jìn)行通信

            服務(wù)器類型

            服務(wù)器類型大致分為邏輯服務(wù)器,戰(zhàn)斗服務(wù)器, 中心服務(wù)器

            邏輯服務(wù)器

            邏輯服務(wù)器負(fù)責(zé)日常邏輯及公共邏輯處理(好友, 公會)

            1個(gè)邏輯服務(wù)器對應(yīng)一個(gè)區(qū), n個(gè)區(qū)均使用Ucloud云Mongodb進(jìn)行數(shù)據(jù)存儲

            戰(zhàn)斗服務(wù)器

            戰(zhàn)斗服務(wù)器是一個(gè)集群, 集群會返回一個(gè)負(fù)載最低的服務(wù)器返回使用

            戰(zhàn)斗服務(wù)器通過cgo技術(shù)與客戶端C++/lua的戰(zhàn)斗邏輯進(jìn)行邏輯復(fù)用, 在此技術(shù)上進(jìn)行

            戰(zhàn)斗邏輯的校驗(yàn)

            中心服務(wù)器

            客戶端登陸前, 在中心服務(wù)器這里獲得可登陸的邏輯服務(wù)器地址, 同時(shí)做一個(gè)負(fù)載均衡

            短連接

            評價(jià)

            由于操作系統(tǒng)的技術(shù)趨于穩(wěn)定, 同時(shí), 手游的弱交互型導(dǎo)致的游戲架構(gòu)趨于簡單. 因此網(wǎng)絡(luò)負(fù)載不再是游戲服務(wù)器技術(shù)的瓶頸. 從經(jīng)驗(yàn)看來, 游戲服務(wù)器技術(shù), 更重要的是還是看數(shù)據(jù)庫的選型及處理方式. 

            雖然Mongodb的性能上不如內(nèi)存數(shù)據(jù)庫. 但是從存儲安全性上要比個(gè)人搭建的內(nèi)存數(shù)據(jù)庫簡單, 安全

            外加上云技術(shù)的引用, 性能的瓶頸和運(yùn)維的技術(shù)復(fù)雜度迎刃而解

            Redis用于跨服數(shù)據(jù)交互那是再好不過的數(shù)據(jù)中介了, 保證速度和穩(wěn)定性, 絕對不是造輪子能比擬的

            短連接在手游上處理起來比長連接簡單一些, 無需做斷線重連. 服務(wù)器的底層也是由Golang的框架庫保證質(zhì)量的. 因此負(fù)載毫無問題. 服務(wù)器對內(nèi)及對外均使用json進(jìn)行數(shù)據(jù)交換, 簡化了協(xié)議處理. 也方便了調(diào)試

            json rpc的性能損耗對于整個(gè)邏輯的處理來說均可以忽略不計(jì)

            posted on 2015-07-21 10:30 戰(zhàn)魂小筑 閱讀(5173) 評論(8)  編輯 收藏 引用 所屬分類: 網(wǎng)絡(luò) 服務(wù)器技術(shù) 、Golang

            評論

            # re: 大服務(wù)器架構(gòu)討論 2015-07-21 10:43 小強(qiáng)哥
            各個(gè)邏輯服務(wù)器之間的玩家有數(shù)據(jù)交互嗎?如果有,那么只是通過redis之間從mongo里把數(shù)據(jù)取出來,中間沒有一個(gè)統(tǒng)一的數(shù)據(jù)服務(wù)來做一些同步操作嘛?  回復(fù)  更多評論
              

            # re: 大服務(wù)器架構(gòu)討論 2015-07-21 10:44 戰(zhàn)魂小筑
            @小強(qiáng)哥
            每個(gè)區(qū)之間會有跨服邏輯, 跨服通過redis交互數(shù)據(jù)
            同步操作都是服務(wù)器之間自己完成, 無需中間服務(wù)器進(jìn)行同步  回復(fù)  更多評論
              

            # re: 大服務(wù)器架構(gòu)討論 2015-07-22 14:52 QQ:79039039-8
            請問對于全局狀態(tài),也是redis來緩存?
            應(yīng)該需要全局鎖操作吧,數(shù)據(jù)是否有多份呢?

            否則,這個(gè)架構(gòu)本身還是存在單點(diǎn)故障/瓶頸吧。(當(dāng)然要分析目標(biāo)玩家數(shù)量)。

            我也在成都,下次有討論叫上我啊~  回復(fù)  更多評論
              

            # re: 大服務(wù)器架構(gòu)討論 2015-07-22 14:53 戰(zhàn)魂小筑
            @QQ:79039039-8
            加我的群討論吧

            redis只是兩個(gè)服務(wù)器間某種邏輯的數(shù)據(jù)交換. 其實(shí)一般這種交換對數(shù)據(jù)的時(shí)效性要求不是那么及時(shí). 鎖沒必要的  回復(fù)  更多評論
              

            # re: 大服務(wù)器架構(gòu)討論 2015-08-31 09:49 freeeyes
            服務(wù)器開發(fā)實(shí)際上有兩種模式。
            一種是你說的Actor模式,實(shí)際上,這種模式的關(guān)鍵是極度信賴內(nèi)部網(wǎng)絡(luò),雖然邏輯可以分散,但是在設(shè)計(jì)上,你必須做到數(shù)據(jù)消息狀態(tài)的解耦,否則,會給未來調(diào)試和測試帶來很多的問題。
            無狀態(tài)數(shù)據(jù),一般選擇http類似協(xié)議(因?yàn)楝F(xiàn)成,簡單高效,可以和腳本語言方便整合,適合移動網(wǎng)絡(luò)),一般情況下,Gate模式是比較受歡迎的。數(shù)據(jù)在入口驗(yàn)證,所有的邏輯依靠后面負(fù)載的各種服務(wù)器(一般的情況可以選擇部分中間件作為消息傳遞手段,比如thrift,ice,tao等)。這種分布的基礎(chǔ)在于數(shù)據(jù)的流向并不確定,你不知道數(shù)據(jù)的下一個(gè)命中點(diǎn)在哪個(gè)服務(wù)器,所以對于持久化的數(shù)據(jù)(比如用戶信息,玩家數(shù)據(jù)等)必須支付更多的IO成本去做維護(hù)統(tǒng)一。那么,在這樣的模式下,服務(wù)器架構(gòu)的穩(wěn)定性,就被壓在IO上了。在排錯(cuò)過程中,你必須確認(rèn)數(shù)據(jù)在IO上的流動,從而需要支出部分維護(hù)架構(gòu)的開發(fā)成本。并且最大的保證內(nèi)部IO的穩(wěn)定,當(dāng)模塊變多和設(shè)計(jì)上的耦合需要,隨著功能的復(fù)雜,模塊間交互的增加,未來維護(hù)成本會較高。
            一種是面向數(shù)據(jù)狀態(tài)的負(fù)載,這種相對比較好理解,比如前幾年的一些MMO游戲,這種模式開發(fā)的依賴不是IO,同樣可以支持Gate模式,但是,數(shù)據(jù)流的方向是指定的,也就是說,服務(wù)器的處理不以單獨(dú)一個(gè)功能模塊劃分,而是以一組的形式存在。一組服務(wù)在一臺主機(jī)上,這種模式依賴的是內(nèi)存的效率。一般是采用共享內(nèi)存節(jié)省數(shù)據(jù)交換的成本。這種狀態(tài)的模式,很難做到精確的負(fù)載均衡,而更加考驗(yàn)的是,你的駕馭邏輯的能力,這里必須強(qiáng)調(diào)的前期的數(shù)據(jù)組織和開發(fā)能力。
            兩種模式的比較,實(shí)際是你信任IO還是信任內(nèi)存。你把維護(hù)放在需求開發(fā)后還是需求開發(fā)前的問題。
            在實(shí)際開發(fā)過程中,沒有萬能藥,最關(guān)鍵的是,如何利用已有的資源去解決需求提出的問題。開發(fā)的關(guān)鍵,是把復(fù)雜變簡單。
            最關(guān)鍵的是,架構(gòu)是為人服務(wù)的,關(guān)鍵是要做到隔離性,獨(dú)立性,可維護(hù)性以及可替換性。  回復(fù)  更多評論
              

            # re: 大服務(wù)器架構(gòu)討論 2015-08-31 09:56 戰(zhàn)魂小筑
            @freeeyes
            非常給力的評論!  回復(fù)  更多評論
              

            # re: 大服務(wù)器架構(gòu)討論 2015-08-31 14:21 freeeyes
            有興趣可以一起研究可服用的服務(wù)器架構(gòu)?  回復(fù)  更多評論
              

            # re: 大服務(wù)器架構(gòu)討論 2015-12-01 17:04 mmocake
            Actor模式非常贊  回復(fù)  更多評論
              

            久久精品无码一区二区日韩AV| 国产精品99久久久精品无码| 久久精品嫩草影院| 国产精品热久久毛片| 偷窥少妇久久久久久久久| 久久综合给合久久狠狠狠97色69 | 久久国产乱子伦精品免费午夜| 国产精品免费久久久久影院| 精品国产日韩久久亚洲| 午夜不卡888久久| 国产亚洲精久久久久久无码77777| 久久精品国产精品亚洲精品| 久久精品国产亚洲AV久| 久久91这里精品国产2020| 久久精品国产精品亚洲精品| 久久久久人妻一区精品| 久久偷看各类wc女厕嘘嘘| 一本久久免费视频| 久久国产精品视频| 亚洲国产成人久久精品影视| 久久久久人妻一区二区三区vr | 人妻无码久久精品| 国内精品久久久久久久coent| 久久久久成人精品无码中文字幕| 一本久久a久久精品综合香蕉| 久久久久无码国产精品不卡| 午夜不卡888久久| 久久99国产一区二区三区| 精品久久久久久中文字幕| 国内精品久久久久影院日本| 亚洲欧美成人综合久久久| 久久人人爽人人爽人人爽| 欧美精品国产综合久久| 中文字幕久久精品无码| 亚洲精品美女久久777777| 久久亚洲精品成人AV| 久久精品天天中文字幕人妻| 国产美女久久精品香蕉69| 久久男人Av资源网站无码软件| 久久人人爽人人爽人人片av高请 | 一本色道久久综合亚洲精品|