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

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

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

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

表格可如下：
NPC名字  類型  

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

玩家的一次登陸操作

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

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

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

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

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


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

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

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


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

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

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

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

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

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


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

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

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

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

所以就是     
                 -LOGINSERVER   -|

                 - LOGINSERVER  -|

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

或者是：

        

        - LOGINSERVER   -             
         - LOGINSERVER   -   
         - LOGINSERVER   - 
      ..................................上面可以是N個                                                                             
        -                                -gameagent -GAMEDBSYSTEM 
        -GAMESERVER  -

Client
       - LOGINSERVER   -      
         - LOGINSERVER   -   
         - LOGINSERVER   - 
      ..................................上面可以是N個                                                                                            
                                         - gameagent-GAMEDBSYSTEM 
        - GAMESERVER  -

  accountagent    --              --- ACCOUNTDBSYSTEM 是全局的

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


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


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