本文小弟淺談，新手看，老手拍磚，轉(zhuǎn)載請注明出處http://www.shnenglu.com/ziyebuboka/

    游戲服務(wù)器在網(wǎng)游上的作用不容考慮，游戲能做大到什么程度，還是有很大的依靠的，這篇文章先從功能模塊的角度來談一個(gè)完善的游戲服務(wù)器需要實(shí)現(xiàn)哪。
    一：游戲服務(wù)器的作用：連接各個(gè)網(wǎng)游客戶端，實(shí)現(xiàn)各客戶端的通信，連接，數(shù)據(jù)操作
    二：先從大分類上來：游戲服務(wù)器按一般架構(gòu)來說具備1
            1:登陸驗(yàn)證注冊和賬號有關(guān)的所有操作的服務(wù)器  我們簡稱他為registerserver
            2：游戲邏輯操作服務(wù)器 我們簡稱他為gameserver
            不用細(xì)說大家也明白了，說一個(gè)玩家登陸進(jìn)入游戲世界的流程：玩家打開游戲客戶端（這之前會(huì)有更新操作，不過這只是連接更新服務(wù)器的一個(gè)文件比對和下載過程，我們不將他列為游戲服務(wù)器之內(nèi)）說到這里朋友會(huì)發(fā)現(xiàn)游戲登陸上目前有兩大類，一類是先選服務(wù)器后輸入賬號 一類是先輸入賬號后選服務(wù)器，這里說下區(qū)別
先選服務(wù)器后輸入賬號的一般來說都是將registerserver和gameserver配對，就是你先選擇服務(wù)器，而后你連接上的就是此服務(wù)器的registerserver，通過此registerserver來進(jìn)行賬號驗(yàn)證等等。另一類先輸入賬號的，無非是先制定一個(gè)中心registerserver（或者是隨機(jī)一個(gè)，因?yàn)閞egister有時(shí)候會(huì)弄好多個(gè)由運(yùn)維配置來做動(dòng)態(tài)均衡），賬號驗(yàn)證成功后再顯示服務(wù)器列表，然后玩家選擇了服務(wù)器后，則從指定服registerserver去數(shù)據(jù)庫查詢玩家此服的角色列表（當(dāng)然了，這里如果非有人的服務(wù)器是做成查詢角色列表就從gameserver走的流程，我也沒意見）。返回后，客戶端進(jìn)入角色選擇界面，客戶端與registerserver斷鏈，玩家選擇角色，與gameserver連接，去數(shù)據(jù)庫提取角色，注冊進(jìn)入游戲服游戲世界，反饋角色信息給客戶端，客戶端進(jìn)入游戲世界。然后消息發(fā)送過來發(fā)送過去的開始了。。。。。。
            上面說的是針對一個(gè)普通的一對一架構(gòu)的服務(wù)器所有的一個(gè)登陸流程，看到這里，朋友們應(yīng)該對registerserver和gameserver的基本功能有所了解了。一個(gè)是登陸驗(yàn)證用（垃圾點(diǎn)的小公司沒有注冊賬號的主頁的話也會(huì)通過這個(gè)在游戲里直接注冊賬號。。。）到登陸進(jìn)入游戲世界的過程。
             再稍微高級點(diǎn)的就是加個(gè)聊天服務(wù)器了，因?yàn)榱奶爝@個(gè)功能實(shí)在是太耗性能了，特別那啥的那公聊，你發(fā)個(gè)一句，服務(wù)器得有多少人就發(fā)多少回。。。
 打個(gè)比方你發(fā)一句話 50個(gè)字那就是100 一個(gè)服有那么個(gè)幾K人的話，就打比方5K人 一句話發(fā)送就得是一個(gè)全服人口大FOR循環(huán)，網(wǎng)絡(luò)還得消耗掉5000*100字節(jié)
所以你看各游戲公聊國聊那啥的都時(shí)間限制要不就收費(fèi)，他扛不住啊。
             所以這個(gè)地方就出來個(gè)性能優(yōu)化方案了，加個(gè)聊天服務(wù)器，也就是玩家在登陸成功與gameserver連接成功的同時(shí)要與聊天服務(wù)器連接成功，聊天服務(wù)器有個(gè)全服在線角色表，一個(gè)大FOR循環(huán)和那啥的5000*100就讓他來發(fā)吧，至少對gameserver沒影響了。
             好了，一個(gè)普通服務(wù)器的基本介紹就說到這里，讀者也應(yīng)該有個(gè)基本了解了，具體架構(gòu)上的就不細(xì)說了，趕明換個(gè)帖子發(fā)。這里還是接標(biāo)題從功能上來分析服務(wù)器。
            這里就只分析游戲服務(wù)器了，registerserver就不考慮了。
            一個(gè)游戲服務(wù)器他的作用在與，所有的游戲數(shù)據(jù)操作都將在這里完成，我們將只將客戶端作為顯示和一個(gè)數(shù)據(jù)的完善緩存。一切的操作都必須在游戲服務(wù)器的驗(yàn)證之后才能完成。
           功能模塊分類（本人之間，有多余或遺漏的，歡迎補(bǔ)充）：
              1：腳本模塊
              2：屬性模塊
              3：網(wǎng)絡(luò)模塊
              4：數(shù)據(jù)庫模塊
              5：日志模塊
以上所列的為一個(gè)完善的游戲服務(wù)器所必須實(shí)現(xiàn)的功能 下面一一來說
1：腳本模塊
      沒有腳本模塊，腳本策劃就得喝西北風(fēng)，LUA首選很不錯(cuò)。
      具體LUA的學(xué)習(xí)，推薦LUA程序設(shè)計(jì)，這玩意不用深究，會(huì)即可。
      程序員要寫好幾個(gè)CPP，完成的功能是---》在C++中任意的調(diào)用LUA函數(shù)（或是執(zhí)行一個(gè)LUA文件），在LUA中任意調(diào)用你提供給腳本策劃的C++函數(shù)接口，如此功能實(shí)現(xiàn)后，哈哈，程序員們，你們的工作負(fù)擔(dān)就輕了，很大一部分的邏輯編程將交給策劃們?nèi)ネ瓿闪?br>     舉例：程序?qū)崿F(xiàn)一個(gè)接口例如 say(LPCSTR szSay)  ，則策劃可調(diào)用此接口 function  mySay()  say("歡迎來到游戲世界") end，就可
    可用到的地方：具體物品的使用邏輯，特殊任務(wù)的邏輯，活動(dòng)邏輯，特殊NPC邏輯等等等等，只要你愿意，跑步都可用LUA來
     比如C++里可實(shí)現(xiàn)一籃子接口：AddItem 增加個(gè)物品  ChangeMap 跳地圖 甚至是AddLevel等等 而由LUA調(diào)用此類接口，而后就是C++里做些操作，比如玩家點(diǎn)擊物品就是調(diào)用相應(yīng)物品的腳本：例：點(diǎn)擊 血瓶 調(diào)用 LUA 的血瓶腳本，執(zhí)行LUA函數(shù)調(diào)用AddHp
     腳本模塊很重要，可極大的方便工作，還有調(diào)試和維護(hù)，因?yàn)樾薷哪_本，服務(wù)器是不用重編譯的，則意味著可在調(diào)試中隨意修改，甚至可在運(yùn)營過程中隨意修改某物品功能 某任務(wù) 某活動(dòng)。。。，只需C++到LUA，把這個(gè)LUA函數(shù)RELOAD下即可
     具體的游戲應(yīng)用腳本的例子 大家網(wǎng)上找找吧 一坨子開源的。
2：屬性模塊：呵呵，不知道我取這個(gè)名字OK不OK，我也覺得不是很合適，大家又更好的命名沒？
     NPC的基本屬性配置，物品的基本屬性配置，叫屬性配置可能更合適點(diǎn)，意思就是你要提供一個(gè)模塊供策劃可填入各個(gè)屬性配置，甚至是GUI的配置又或者是任務(wù)配置。對于這個(gè)，我推薦使用EXCEL表格。
    例如：NPC的表格至少包括  NPC名字  模型編號   血量    藍(lán)量   移動(dòng)速度    AI  等等，而后有策劃往里面隨意填配置 這里比如AI就是一個(gè)對應(yīng)的腳本文件
     這個(gè)讀取表格由程序員實(shí)現(xiàn)，功能是要求要自由化，不然的話 策劃加一條 你咋辦，不至于從讀取開始你的代碼都得改吧，肯定能做到直接在NPCPROPERTY結(jié)構(gòu)體里直接加一條和表格新加的對應(yīng)就OK了。
   如果OK得話，最好再提供個(gè)編輯工具給策劃，任務(wù)的相同模式也可由此來實(shí)現(xiàn)：任務(wù)描述  任務(wù)要求 對話1  對話2  對話3  獎(jiǎng)勵(lì)1 獎(jiǎng)勵(lì)2 獎(jiǎng)勵(lì)3
   物品：物品名字 模型編號 職業(yè)   等級   攻擊  腳本  
   不然你總不至于傻到認(rèn)為這些都是寫代碼里的吧。也可能有人想使用XML  隨便了 不過我這里不想用XML 為啥  EXCEL清晰啊 就一行條目
    這個(gè)模塊是數(shù)值策劃 任務(wù)策劃的天下
3：網(wǎng)絡(luò)?？欤哼@個(gè)沒啥好說的  一個(gè)基本功能，游戲世界都是在這之上也能成型，做好鏈接維護(hù)，收發(fā)消息
4：數(shù)據(jù)庫模塊：對數(shù)據(jù)的保存 其實(shí)這里我熱衷于使用工廠模式，本地調(diào)試服務(wù)器具體邏輯用本地文檔方式，上測試服上外網(wǎng)則用數(shù)據(jù)庫，所以這里叫數(shù)據(jù)操作模塊比較妥當(dāng)點(diǎn)，就是玩家保存數(shù)據(jù)，保存幫派啦 等等世界信息的具體操作，這個(gè)很重要
5：日志模塊：我將此日志模塊分為兩大類，一類是游戲服務(wù)器調(diào)試維護(hù)用日志，一類是游戲運(yùn)營用日志，可選擇使用本地文檔或是數(shù)據(jù)庫模式記錄
    調(diào)試維護(hù)日志沒啥好說的，運(yùn)營日志說說，是給客服提供的，誰消費(fèi)了什么 交易流向 物品流向 等等的記錄 GM操作的記錄等等 比如萬一某玩家裝備被盜了，則可通過此來證明。

 接著一繼續(xù)，其實(shí)寫本文從內(nèi)行技術(shù)角度來看，本身就沒什么技術(shù)含量，但是俗話說的好，隔行隔山，內(nèi)行看門道，外行那啥什么，反正就是想觸碰這玩意，但是又沒搞過的人看的。反正都是隨便亂寫了，愛看的看，準(zhǔn)備寫個(gè)功能模塊大概 再寫個(gè)架構(gòu)得大概，而后就去從網(wǎng)絡(luò)包開始搞個(gè)最簡單最輕量的小架構(gòu)，力圖讓知道編程是啥的就能在上面搞東西
      還是繼續(xù)談功能模塊。
      一、還有個(gè)  AI模塊，這個(gè)可不能忘啊
      不過要注意，我這里提到的AI模塊和我一里面所提到的幾個(gè)AI地方說指AI不是一會(huì)事情。
      這里的AI模塊，哈哈，就是所謂的算法了，算法達(dá)人們NB的地方了。
      針對NPC怪物等，比如最基本的尋路算法。
      此模塊達(dá)到的效果是什么呢，就是：怪物死了又活，怪物看見你知道追你，怪物知道打你 都知道尋路躲障礙
      介紹下最基本的A*算法吧 什么A B C D E F D的
      怪物要打你 得追你，但是他為啥知道跟你走呢，或者說你點(diǎn)擊一個(gè)地方，為啥就能自動(dòng)走過去，能自動(dòng)的繞開障礙呢。這個(gè)模塊就是實(shí)現(xiàn)這些基本的東西。
      2D的一般都是按格子計(jì)算，就說2D了，還有用像素玩的，3D玩坐標(biāo)的，等等 其實(shí)都是一會(huì)事情
      角色身旁一共有8個(gè)格子，你點(diǎn)擊一個(gè)地方，就等于是指明了一個(gè)方向，角色就找到正對方向的身旁最近格子，判斷此格子是否有阻擋，如果無則走過去，如果有阻擋則搜索身旁另一個(gè)格子，然后就是這么一直遞歸，知道到達(dá)終點(diǎn)格子。
     基本的自動(dòng)尋路算法就是上面這么一段話，當(dāng)然實(shí)際操作中，肯定不會(huì)用這么費(fèi)效率的算法了，這里就是簡單介紹下這個(gè)活在N-》B之前的N-》A*算法。。NA啊。具體的大家可以去找本人工智能的書看看
     服務(wù)器要算一下怪物走哪了就給周圍玩家同步下消息，所以服務(wù)器需要這玩意，這理由充分吧、、、
     客戶端也需要，給玩家或者寵物自動(dòng)尋路，內(nèi)掛使用。
    為什么我說這里的AI和我在一里面說的不同呢，是因?yàn)檫@里是實(shí)行基本的自動(dòng)功能，而后你可以在這個(gè)模塊的基礎(chǔ)上發(fā)展高級AI智能，結(jié)合腳本，表格配置，活用技能。比如一個(gè)游戲里按檔次有白怪 藍(lán)怪  紫怪 BOSS
白怪么就給他這一套最基本的會(huì)走路躲障礙會(huì)打人就可
藍(lán)怪 稍微高級點(diǎn)了，在基本模塊上擴(kuò)展，程序里再實(shí)現(xiàn)血少到一定程度會(huì)逃跑 會(huì)喊同伙，

以上兩種可根據(jù)屬性配置表格模塊根據(jù)怪物類型讀取到程序，程序根據(jù)類型判斷是否激活擴(kuò)展AI

表格可如下：
NPC名字  類型  

紫怪  再高級點(diǎn) 定制AI，可在程序里預(yù)先定義一組高級AI，比如預(yù)先設(shè)想好的十種可能，打個(gè)比方，放A技能 放B技能 自動(dòng)加血等等 ，而后也可在表格配置，比如預(yù)先表格設(shè)定好一種怪物最多可有4個(gè)定制AI

表格可如下：
NPC名字  類型  定制AI1 定制AI2 定制AI3 定制AI4

程序讀取到相應(yīng)類型而激活相應(yīng)模塊 或者此組AI 都用腳本預(yù)先寫好 也不錯(cuò) 這樣比寫死在程序里好

BOSS  那就得完全特殊處理了不是，腳本發(fā)揮作用，完全腳本實(shí)現(xiàn)  程序事先一組接口，比如掉什么裝備接口，放技能的接口等等，LUA里面就狂寫吧，接口只要完善，寫成個(gè)WOW里的一樣也很OK

表格可如下：
NPC名字  類型  定制AI1 定制AI2 定制AI3 定制AI4  腳本AI

像2D游戲 下FB BOSS不夠智能的話 玩家就知道卡BOSS 幾個(gè)玩家把BOSS圍一圈，讓外面的遠(yuǎn)程玩家打，格子上玩家又是不可重復(fù)的，BOSS就出不去 有仇恨系數(shù) 他又只想殺外面打他的玩家 導(dǎo)致就卡那里了，想打的玩家打不到 打的到的玩家又不想打。。。。。。。怎么辦呢，特殊AI處理，卡BOSS？系統(tǒng)判斷BOSS十秒不出手，就放大技能秒殺周圍的人。。。。
     
說到底，AI模塊就是最基本算法，程序定制，腳本定制，屬性表格配置再加腳本特殊化處理，基本就可達(dá)到需求了

二：擴(kuò)展下前面說的數(shù)據(jù)庫模塊和日志模塊
        這里大家要注意，在這類數(shù)據(jù)庫 和IO操作上 盡量使用別的線程來開，不要和主線程搞到一起
 按目前流行的架構(gòu)，一般都是在服務(wù)器上多開線程開啟網(wǎng)絡(luò)接口，另外在專門單開代理程序，消息發(fā)送到數(shù)據(jù)代理，讓代理來實(shí)現(xiàn)數(shù)據(jù)操作。
       日志模塊，本地調(diào)試么，就用文檔記錄，運(yùn)營日志，單開個(gè)代理吧，這個(gè)操作挺頻繁的，和登錄保存角色的代理放一起影響性能 而且每什么意思，畢竟這個(gè)異步互相是不關(guān)聯(lián)的  稍微提醒下就是 你要是做 物品流向的時(shí)候 切記不要所有物品都記啊 不然就SB了，這個(gè)流向日志 要是都記錄的話 那一天都不知道是多少萬條記錄了 萬？十萬？百萬？
   可以 表格配置：
  物品名字  物品ID  是否記錄日志    //后面其他列是其他屬性
每次產(chǎn)生物品流向時(shí)候 比如買一個(gè)裝備到包里  交易一個(gè)裝備 等等
if(pItemProperty->bCanSaveLog)
{
//sendmessagetologdb
}  

這樣你就記錄些珍貴物品就可

按我的分類 我一般將代理分為 賬號代理  角色代理  游戲代理  日志代理  運(yùn)維控制器代理

這里不一個(gè)個(gè)講了 放到后面說架構(gòu)的時(shí)候再說每個(gè)代理需要做的事情 
一個(gè)宗旨是 分的細(xì) 每一個(gè)得壓力就小  但是要保證不要出現(xiàn)數(shù)據(jù)互交叉

也見過某些項(xiàng)目 是沒有具體的數(shù)據(jù)操作代理的，直接是在服務(wù)器里直接操作，我個(gè)人認(rèn)為啊，能新開進(jìn)程 異步的 就開，沒必要給老板省錢，全部都壓一GAME上 扛不住啊，而且如果是分布式的話，你肯定得有一個(gè)統(tǒng)一的數(shù)據(jù)出口啊，不然的話。。我沒想過會(huì)怎樣，數(shù)據(jù)不統(tǒng)一？數(shù)據(jù)庫死鎖?

三：運(yùn)維模塊
     運(yùn)維分開就是運(yùn)營和維護(hù)。。  因?yàn)樗麄兪亲叩耐惶准軜?gòu)，所以這里就放一起來說
     首先說明他們的產(chǎn)生原因：不可能每一次服務(wù)器更新 或者再監(jiān)控服務(wù)器 維護(hù)過程 或者是提取某某文件日志  都是一個(gè)個(gè)遠(yuǎn)程硬件服務(wù)器吧 那樣的話 維護(hù)者工作效率就太低了
     GM也不可能每一個(gè)服務(wù)器都登陸進(jìn)個(gè)客戶端開著吧。。所以這個(gè)模塊就產(chǎn)生了，對維護(hù)者是要實(shí)現(xiàn)他們的遠(yuǎn)程操作，對GM是要實(shí)現(xiàn)他們的線下操作。
    工具功能：可監(jiān)控 開啟  關(guān)閉服務(wù)器 可主動(dòng)推送更新文件 更新腳本 
                       GM可線下操作基本命令，監(jiān)控聊天，賠償物品，發(fā)送游戲郵件等等。
                       開發(fā)者可主動(dòng)提取調(diào)試日志記錄
                       算帳的可主動(dòng)開后臺查看運(yùn)營日志記錄計(jì)算ARPU值，查看在線記錄，等等等等
我現(xiàn)在是不推薦GM做線上操作的呢，就如同之前傳奇那樣的，都是在聊天框里輸入GM命令，我個(gè)人認(rèn)為內(nèi)部操作還是走后門的好 不要和玩家一起從前門走了，注意的是這一塊在中心控制器代理這里一定要做好監(jiān)控，和操作記錄，驗(yàn)證，來保證操作的安全性，防止違規(guī)操作。力圖將工具客戶端綁定到某一臺機(jī)器，比如可在運(yùn)維登陸工具時(shí)候 發(fā)送賬號 密碼  MACKEY  IP  子網(wǎng)掩碼   某一個(gè)CODE 等等在控制中心驗(yàn)證 成功才可登入控制中心，工具客戶端才可操作、
     這個(gè)模塊主要注意的就是安全性，操作的方便，和日志模塊結(jié)合在一起，日志記錄 分類 挖掘 良好 


    具體架構(gòu)的后面再說
    畢竟這個(gè)就是淺談，所以沒有什么實(shí)際性的代碼內(nèi)容，就是讓不了解的朋友能夠了解這是怎樣的一個(gè)架構(gòu)一個(gè)工作流程
    看了留言啊 ，這博客，不同IP，點(diǎn)了就加一閱讀，沒意思啊，我不知道到底有沒有價(jià)值繼續(xù)啊，

    我是力圖用最淺的語言來表現(xiàn)這些玩意是怎么會(huì)事情，高深的我也不懂了，扁我吧，。覺得沒啥意思的也留個(gè)言拍下磚頭啊，覺得有意思的留個(gè)言讓我高興下，主要是沒打草稿直接寫的就發(fā)了，遺漏 不清不楚肯定還是有的 .

本文介紹一下一個(gè)應(yīng)用的游戲服務(wù)器的架構(gòu)和演變
      游戲服務(wù)器的作用在于滿足在線玩家的需求，實(shí)現(xiàn)賬號的驗(yàn)證，登陸，玩家在游戲世界的一系列邏輯操作和驗(yàn)證。在此基礎(chǔ)上，一個(gè)好的架構(gòu)，可以提升效率，在實(shí)現(xiàn)邏輯需求的情況下達(dá)到百萬級的同時(shí)在線數(shù)也不是不可能。
      我們先從最搓的最簡單的結(jié)構(gòu)看起
      
      CLIENT ----------  SERVER   ---------   DBSYSTEM

      就是一個(gè)很簡單的 C/S系統(tǒng)  同一個(gè)server同時(shí)處理登陸注冊創(chuàng)建角色和游戲邏輯操作的功能，。在server上直接掛接DB操作。DB可以是一個(gè)具體的數(shù)據(jù)庫也可以是一個(gè)FILESYSTEM
      這里可以看的出來，過于簡單了，將登陸注冊創(chuàng)建和具體邏輯這幾個(gè)毫無關(guān)系的東西放置于一起，嚴(yán)重?fù)p耗了具體邏輯操作的效率，特別是在新開服階段，完全會(huì)因?yàn)榈顷戲?yàn)證的操作而導(dǎo)致邏輯爆卡。
      所以這里需要升級，將完全不同類型在玩家一次游戲操作工程中只會(huì)在登陸階段執(zhí)行一次的操作單獨(dú)分開，單獨(dú)進(jìn)程解決，。故而可成為下面階段
       
                 -  LOGINSERVER -
               -                                 -
CLIENT -                                   -  DBSYSTEM
               -                                -
                - GAMESERVER -

分為兩個(gè)服務(wù)器，這個(gè)我在一文章里的開頭就有提到過了。

我們來看下好處進(jìn)階，在LOGINSERVER里只執(zhí)行賬號驗(yàn)證  查詢角色列表  創(chuàng)建角色的操作   而后玩家登陸進(jìn)GAMESERVER  具體邏輯操作在GAMESERVER里完成

玩家的一次登陸操作

                   發(fā)送賬號                                 驗(yàn)證                               返回角色列表                          創(chuàng)建角色
CLIENT---------------LOGINSERVER -----------DBSYSTEM-----------------------CLIENT ------------------
                                                                                                選擇角色與LOGIN斷鏈與GAME連接 登陸
LOGINSERVER -------DBSYSTEM  ----------CLIENT  ------------------------------------------------------GAMESERVER

如此，可有效的提升效率，玩家的驗(yàn)證 列表讀取 創(chuàng)建 和GAME就毫無關(guān)系了，但是他的缺點(diǎn)任然存在 我們再繼續(xù)看可優(yōu)化的地方

首先從數(shù)據(jù)庫上來提升效率（先說下，從這里開始就應(yīng)該是肯定的是用數(shù)據(jù)庫了，而非什么本地FILE了，），將賬號庫和游戲數(shù)據(jù)庫分開，分離為兩個(gè)獨(dú)立的庫，
具體理由有兩個(gè)：
1：從游戲運(yùn)營上來說 你不可能一直是只有一個(gè)服吧？ 分成多個(gè)服后 人數(shù)越來越多，就不能所有服都共用一個(gè)數(shù)據(jù)庫了吧？那你這數(shù)據(jù)庫也牛逼了
      所以我們這里這么干，將 賬號庫獨(dú)立，全游戲共用，這樣是方便管理，方便管理賬號的全局性的信息 經(jīng)濟(jì)性的 比如點(diǎn)卡什么的，每個(gè)服一個(gè)游戲數(shù)據(jù)庫，只記錄操作你這個(gè)服的玩家信息，世界信息。
2：理由類同將服務(wù)器拆分為LOGIN和GAME。

現(xiàn)在 結(jié)構(gòu)就是這樣的

                   - LOGINSERVER-
                 -                               - ACCOUNTDBSYSTEM
 CLIENT -                                                             -   
                 -                               - GAMEDBSYSTEM 
                   - GAMESERVER -


但是到了這里后 肯定還是不夠的，
我們先說個(gè)基本的，在服務(wù)器里 ，你一定要記得，數(shù)據(jù)庫操作，IO操作 ，文本操作這些 一定要單獨(dú)進(jìn)程不要和主進(jìn)程搞一起，你總不希望你做了個(gè)什么查詢還是什么操作 他主線程掛起吧？但是，試想下，如果能單獨(dú)進(jìn)程肯定還是單獨(dú)進(jìn)程更爽一點(diǎn)吧？你還能在里面做做緩存啥的，還不占服務(wù)器的資源
    所以這里還是麻煩的 從效率上來說 至少后臺這塊 還有很大提升空間。因此，我們加入 DBAGENT模塊 ，單獨(dú)進(jìn)程，將數(shù)據(jù)庫操作單獨(dú)分離，并且可自我添加某些應(yīng)用的緩存

對應(yīng)ACCOUNTDBSYSTEM 增加 accountagent ，對應(yīng) GAMEDBSYSTEM 增加 gameagent

結(jié)構(gòu)如下


                 -LOGINSERVER-
               -                              - accountagent - ACCOUNTDBSYSTEM
CLIENT -                                                                                                   
               -                              - gameagent   - GAMEDBSYSTEM 
                -GAMESERVER -

LOGINSERVER同時(shí)和accountagent和gameagent連接   gameserver也同時(shí)和這兩個(gè)連接   服務(wù)器通過agent來對對應(yīng)的數(shù)據(jù)庫做操作   因?yàn)閍ccountdbsystem可能是全服共有的 ，所以accountagent也可以是全服共有的 他連接所有的服務(wù)器。loginserver通過accountagent來驗(yàn)證 通過gameagent來查詢列表 創(chuàng)建角色  gameserver通過gameagent來查詢完整角色信息登陸進(jìn)game，并通知accountagent此賬號已進(jìn)入游戲，避免重復(fù)登陸。并且定期保存。設(shè)置你可以將比如你游戲的排行榜啊，拍賣行啊的信息放置于你自己設(shè)計(jì)的gameagent的緩存中，而避免重復(fù)查詢

玩家每一個(gè)對數(shù)據(jù)庫的操作 server只需發(fā)送消息到agent agent來做具體操作，而后再返回到server 再到client就可。將數(shù)據(jù)操作完全的異步操作，效率有較大提升。并且安全性上也得到了些許保證。

不是我胡說或者輕視，國內(nèi)一大半游戲，都用的上面這個(gè)結(jié)構(gòu)。。。。。。。。。。。。。。。。。。。。。這個(gè)可以算是一個(gè)比較完善的產(chǎn)品化架構(gòu)了。

說到這里，大家有沒有發(fā)現(xiàn)一個(gè)共性。采用這類架構(gòu)，游戲必然會(huì)是先選服務(wù)器再驗(yàn)證賬號 登陸進(jìn)游戲，這是因?yàn)榉?wù)端采用的是LOGIN和GAME一對一得處理，也就是你是登陸的什么服務(wù)器必然就是從什么服務(wù)器的LOGIN進(jìn)入驗(yàn)證，故而他需要在客戶端開啟的時(shí)候就要知道需要連接的是哪個(gè)LOGIN 賬號驗(yàn)證成功后再是哪個(gè)GAME
其實(shí)這里很好處理，就在客戶端上做些處理就可以達(dá)到先登陸驗(yàn)證在選服務(wù)器。所以在配置上 LOGIN不再是一對一（后面會(huì)有優(yōu)化的再說到多個(gè)LOGIN），全局也共用一個(gè)LOGIN。玩家開啟客戶端，連接LOGIN。發(fā)送賬號驗(yàn)證。因?yàn)檫@里已經(jīng)是把ACCOUNTDBSYSTEM做成全局的了，所以是不用擔(dān)心他是哪個(gè)服的，然后返回成功，玩家客戶端顯示服務(wù)器列表（這個(gè)列表還有連接信息配置再客戶端就可以了）選擇某一個(gè)服后，則發(fā)送查詢某服角色列表的請求到LOGIN，而后再返回再登陸游戲就可。小小調(diào)整和改變就可實(shí)現(xiàn)先驗(yàn)證后選服務(wù)器了。

      所以，到了這步，服務(wù)器架構(gòu)就變成這個(gè)樣子了


                  -LOGINSERVER-
                -                               - accountagent -ACCOUNTDBSYSTEM
CLIENT -                                 |--------                                           
                -                                |-----------
                 - 
                  - GAMESERVER  - gameagent     -GAMEDBSYSTEM 
                    -                                             |  
                   - GAMESERVER  -gameagent      -GAMEDBSYSTEM 

全局共用一個(gè)LOGIN和一個(gè)ACCOUNTAGENT還有ACCOUNTDBSYSTEM
每個(gè)獨(dú)立服各自獨(dú)立的gameagent 和gamesdbystem
但是LOGIN的瓶頸立馬出現(xiàn)了，當(dāng)初是一個(gè)服獨(dú)立一個(gè)LOGINSERVER 現(xiàn)在是全服只有一個(gè)了，毫無以為，扛不住。

其實(shí)上面這個(gè)架構(gòu)的不一定非得存在的，就是隨便寫寫，讓大家更清楚一點(diǎn)。

所以LOGINSERVER就得配置多個(gè)了。這個(gè)地方大家選擇吧 盡量靈活點(diǎn)，可以全服單位的配置多個(gè)也可以每個(gè)服對應(yīng)的配置多個(gè)LOGINSERVER。這樣 在開服時(shí)候，這種大面積井噴式的玩家玩家上線，可有效解決負(fù)載。具體CLIENT開啟后會(huì)是和哪個(gè)LOGIN連接呢
這里提供兩種方式。一個(gè)是配置上的 一個(gè)是程序上的
1：
   程序上的好說 ，你把所有LOGINSERVER的連接信息都配置到客戶端，讓客戶端開啟后隨機(jī)選擇一個(gè)去連接。要是你開服后，他所有玩家都隨機(jī)到一個(gè)LOGINSERVER了，那真的算你點(diǎn)背。背到家了
2：配置上 ：
   通過基于DNS的負(fù)載均衡系統(tǒng)，DNS中為一個(gè)域名配置多個(gè)IP地址。通過負(fù)載，讓系統(tǒng)來選擇是對應(yīng)到哪個(gè)IP

所以就是     
                 -LOGINSERVER   -|

                 - LOGINSERVER  -|

                 -LOGINSERVER   -|
                -                  -accountagent -ACCOUNTDBSYSTEM
CLIENT -                                  |--------                                           
                -                                 |-----------
                - 
                -GAMESERVER -gameagent   -GAMEDBSYSTEM 
                -                                             |  
                -GAMESERVER - gameagent  -GAMEDBSYSTEM 

或者是：

        

        - LOGINSERVER   -             
         - LOGINSERVER   -   
         - LOGINSERVER   - 
      ..................................上面可以是N個(gè)                                                                             
        -                                -gameagent -GAMEDBSYSTEM 
        -GAMESERVER  -

Client
       - LOGINSERVER   -      
         - LOGINSERVER   -   
         - LOGINSERVER   - 
      ..................................上面可以是N個(gè)                                                                                            
                                         - gameagent-GAMEDBSYSTEM 
        - GAMESERVER  -

  accountagent    --              --- ACCOUNTDBSYSTEM 是全局的

一個(gè)服對應(yīng)好多個(gè)LOGINSERVER


因?yàn)長OGINSERVER使用的動(dòng)態(tài)配置，故而可在登陸下線沒有多大壓力的情況下，關(guān)掉幾個(gè)LOGINSERVER，節(jié)省運(yùn)維資源


不想寫了，元旦又混了三天，明天繼續(xù)吧。明天把前面的再擴(kuò)展下，再說下分線的和分布的。牛逼的就不說了