• <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)論
              

            …久久精品99久久香蕉国产| 亚洲精品tv久久久久久久久久| 久久亚洲精品成人av无码网站| 亚洲午夜无码久久久久| 久久99免费视频| 97香蕉久久夜色精品国产| 国产精品一区二区久久不卡 | 午夜精品久久久久久99热| 99久久免费国产特黄| 久久久精品久久久久影院| 久久久精品一区二区三区| 亚洲精品乱码久久久久久久久久久久 | 久久久无码精品午夜| 97久久精品人妻人人搡人人玩| 久久人人爽人人爽人人片AV麻豆| 久久人人爽爽爽人久久久| 亚洲中文字幕伊人久久无码 | 青青草国产精品久久久久| 国产亚洲精品久久久久秋霞| 久久99国产精品99久久| 亚洲国产另类久久久精品| 99久久做夜夜爱天天做精品| 久久不见久久见免费影院www日本| 久久精品国产亚洲av麻豆小说| 婷婷久久五月天| 综合久久精品色| 一本一道久久a久久精品综合| 久久精品这里只有精99品| 久久综合九色综合久99| 亚洲国产二区三区久久| 久久精品嫩草影院| 久久精品国产一区| 中文字幕一区二区三区久久网站| 18岁日韩内射颜射午夜久久成人| 久久久综合九色合综国产| 91亚洲国产成人久久精品网址| 久久er热视频在这里精品| 久久国产精品成人免费| 蜜桃麻豆www久久| 久久久久香蕉视频| 一本一道久久a久久精品综合|