• <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 開(kāi)源項(xiàng)目:https://github.com/davyxu

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

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

            概述

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

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

            數(shù)據(jù)庫(kù)

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

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

            通信及協(xié)議

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

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

            服務(wù)器類(lèi)型

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

            邏輯服務(wù)器

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

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

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

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

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

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

            中心服務(wù)器

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

            短連接

            評(píng)價(jià)

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

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

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

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

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

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

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

            評(píng)論

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

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

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

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

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

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

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

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

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

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

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

            久久综合给合久久狠狠狠97色| 久久久久亚洲AV无码网站| 日韩十八禁一区二区久久| 久久人与动人物a级毛片| 国产美女久久久| 日韩精品久久久久久久电影| 久久精品国产免费| 亚洲国产精品成人久久| 久久国产影院| 狠狠色丁香婷综合久久| 亚洲精品国产美女久久久| 久久久久无码专区亚洲av| 久久精品99久久香蕉国产色戒| 久久无码一区二区三区少妇| 国产精品对白刺激久久久| 国产精品99久久久精品无码| 精品国产青草久久久久福利| 奇米综合四色77777久久| 久久只这里是精品66| 久久国产香蕉一区精品| 久久综合综合久久97色| 久久久久久久久无码精品亚洲日韩| 国内精品免费久久影院| 久久久国产精品福利免费| 无码日韩人妻精品久久蜜桃| 久久大香萑太香蕉av| 伊人久久五月天| 婷婷国产天堂久久综合五月| 热RE99久久精品国产66热| 精品国产青草久久久久福利| 国产99久久久久久免费看| 久久综合综合久久97色| 久久久久夜夜夜精品国产| 2021久久国自产拍精品| 国产精品久久久亚洲| 久久精品国产亚洲AV高清热| 蜜臀久久99精品久久久久久小说| 精品多毛少妇人妻AV免费久久| 一97日本道伊人久久综合影院| 女同久久| av色综合久久天堂av色综合在|