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

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

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

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

表格可如下：
NPC名字  類型  

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

玩家的一次登陸操作

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

如此，可有效的提升效率，玩家的驗證 列表讀取 創建 和GAME就毫無關系了，但是他的缺點任然存在 我們再繼續看可優化的地方

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

現在 結構就是這樣的

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


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

對應ACCOUNTDBSYSTEM 增加 accountagent ，對應 GAMEDBSYSTEM 增加 gameagent

結構如下


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

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

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

不是我胡說或者輕視，國內一大半游戲，都用的上面這個結構。。。。。。。。。。。。。。。。。。。。。這個可以算是一個比較完善的產品化架構了。

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

      所以，到了這步，服務器架構就變成這個樣子了


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

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

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

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

一個服對應好多個LOGINSERVER


因為LOGINSERVER使用的動態配置，故而可在登陸下線沒有多大壓力的情況下，關掉幾個LOGINSERVER，節省運維資源


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