首先,二話不說,上圖(用Windows畫圖畫的。。。)
這個圖是一個區(qū)的架構(gòu)圖,所有區(qū)的架構(gòu)是一樣的。上面虛線框的ServerGroup和旁邊方框內(nèi)的架構(gòu)一樣。圖上的所有x N的服務器,都是多臺一起的。紅線,綠線,和藍線圖上也有圖示,這里就不多介紹了。關(guān)于Agent Server大家也能看出來,其實就是Gate。
這里主要介紹下圖上的標記了號碼的位置的數(shù)據(jù)連接的內(nèi)容和意義。
1- 這是一條WebService的管道,在用戶激活該區(qū)帳號,或者修改帳號密碼的時候,通過這條通道來插入和更新用戶的帳號信息。
2- 這也是一條WebService管道,用來獲取和控制用戶該該組內(nèi)的角色信息,以及進行付費商城代幣之類的更新操作。
3- 這是一條本地的TCP/IP連接,這條連接主要用來進行服務器組在登陸服務器的注冊,以及登陸服務器驗證帳戶后,向用戶服務器注冊帳戶登陸信息,以及進行對已經(jīng)登陸的帳戶角色信息進行操作(比如踢掉當前登陸的角色),還有服務器組的信息更新(當前在線玩家數(shù)量等)。
4- 這也是一條本地TCP/IP連接,這條連接用來對連接到GameServer的客戶端進行驗證,以及獲取角色數(shù)據(jù)信息,還有傳回GameServer上角色的數(shù)據(jù)信息改變。
5- 這條連接也是一條本地的TCP/IP連接,它用來進行公共信息服務器和數(shù)個游戲服務器間的交互,用來交換一些游戲世界級的信息(比如公會信息,跨服組隊信息,跨服聊天頻道等)。
6- 這里的兩條連接,想表達的意思是,UserServer和GameServer的Agent是可以互換使用的,也就是玩家進入組內(nèi)之后,就不需要再切換Agent。如果不怕亂套,也可以把登陸服務器的Agent也算上,這樣用戶整個過程里就不需要再更換Agent,減少重復連接的次數(shù),也提高了穩(wěn)定性。(畢竟連接次數(shù)少了,也降低了連不上服務器的出現(xiàn)幾率)
在這個架構(gòu)里面,GameServer實際上是一個游戲邏輯的綜合體,里面可以再去擴展成幾個不同的邏輯服務器,通過PublicServer進行公共數(shù)據(jù)交換。
UserServer實際上扮演了一個ServerGroup的領頭羊的角色,它負責向LoginServer注冊和更新服務器組的信息(名字,當前人數(shù)),并且對Agent進行調(diào)度,對選擇了該組的玩家提供一個用戶量最少的Agent。同時,它也兼了一個角色管理服務器的功能,發(fā)送給客戶端當前的角色列表,角色的創(chuàng)建,刪除,選擇等管理操作,都是在這里進行的。而且,它還是一個用戶信息的驗證服務器,GameServer需要通過它來進行客戶端的合法性驗證,以及獲取玩家選擇的角色數(shù)據(jù)信息。
采用這種架構(gòu)的游戲,通常有以下表現(xiàn)。
1- 用戶必須激活一個大區(qū),才能在大區(qū)內(nèi)登陸自己的帳號。
2- 用戶啟動客戶端的時候,彈出一個登陸器,選擇大區(qū)。
3- 用戶啟動真正的客戶端的時候,一開始就是輸入帳號密碼。
4- 帳號驗證完成之后,進行區(qū)內(nèi)的服務器選擇。
5- 服務器選擇完成之后,進入角色管理。同時,角色在不同的服務器里不能共享。
市面上符合上面幾個表現(xiàn)特征的游戲相當?shù)亩啵乙膊环缡谰拮鳌_@個架構(gòu)不是一個新的架構(gòu),但是它足夠經(jīng)典和完善,并且邏輯簡單而清晰,用來做MMORPG,或者其它網(wǎng)絡游戲的服務器架構(gòu),是一種不錯的選擇。
評論
@alittlewolf
(1) 每組承載量,一般是10000人左右。在目前主流服務器硬件條件下,PublicServer為這些人做服務是輕松的。
(2) UserServer 沒有太大壓力,只是做為一個驗證平臺,角色管理的資源消耗也不大,這個在實際中已經(jīng)驗證過了。
(3) LoginServer 沒什么必要分布式,雖然一般登陸的壓力比較大,但是對于一個組來說,登陸驗證都是消耗最小的一個操作,沒有長期壓力。而且它的硬件條件也是比較好的,所以不用分布式的,那樣會增加整個系統(tǒng)的復雜性。
(4) 一般這種架構(gòu)下,GroupDB和UserServer之間會做一個Cache,杜絕頻繁的數(shù)據(jù)庫讀寫。處于安全性和性能考慮,可以選擇帶有集群功能的數(shù)據(jù)庫。不過從成本出發(fā),一般是單臺的DB服務器,一個庫搞定。
(5) Agent是用來進行用戶過濾,分流和調(diào)度的。同時也是出于安全性考慮。另外也是為了降低后臺服務器的壓力。而且用Agent可以實現(xiàn)很多比較效率的處理方式。 回復 更多評論
(1) 每組承載量,一般是10000人左右。在目前主流服務器硬件條件下,PublicServer為這些人做服務是輕松的。
(2) UserServer 沒有太大壓力,只是做為一個驗證平臺,角色管理的資源消耗也不大,這個在實際中已經(jīng)驗證過了。
(3) LoginServer 沒什么必要分布式,雖然一般登陸的壓力比較大,但是對于一個組來說,登陸驗證都是消耗最小的一個操作,沒有長期壓力。而且它的硬件條件也是比較好的,所以不用分布式的,那樣會增加整個系統(tǒng)的復雜性。
(4) 一般這種架構(gòu)下,GroupDB和UserServer之間會做一個Cache,杜絕頻繁的數(shù)據(jù)庫讀寫。處于安全性和性能考慮,可以選擇帶有集群功能的數(shù)據(jù)庫。不過從成本出發(fā),一般是單臺的DB服務器,一個庫搞定。
(5) Agent是用來進行用戶過濾,分流和調(diào)度的。同時也是出于安全性考慮。另外也是為了降低后臺服務器的壓力。而且用Agent可以實現(xiàn)很多比較效率的處理方式。 回復 更多評論
一些疑問,希望得到博主的解答:
PublicServer要完成跨服組隊信息,跨服聊天頻道功能,那么它不應該放置在方框中,不能屬于特定的組中,因為它還需要和其他組交換數(shù)據(jù)。
ControlAndDataCenter的功能是什么?是不是它僅僅就是一個DB 中心,全國所有區(qū)域服務器的一個數(shù)據(jù)中心,區(qū)域服務器從它拿玩家的帳號信息?
如果是UserServer為什么要連接它,前面在激活時候所有數(shù)據(jù)已經(jīng)獲取到了AreaDB中?
AreaDB僅僅是一個DB它如何通過○1 向ControlAndDataCenter要數(shù)據(jù)?
回復 更多評論
PublicServer要完成跨服組隊信息,跨服聊天頻道功能,那么它不應該放置在方框中,不能屬于特定的組中,因為它還需要和其他組交換數(shù)據(jù)。
ControlAndDataCenter的功能是什么?是不是它僅僅就是一個DB 中心,全國所有區(qū)域服務器的一個數(shù)據(jù)中心,區(qū)域服務器從它拿玩家的帳號信息?
如果是UserServer為什么要連接它,前面在激活時候所有數(shù)據(jù)已經(jīng)獲取到了AreaDB中?
AreaDB僅僅是一個DB它如何通過○1 向ControlAndDataCenter要數(shù)據(jù)?
回復 更多評論
1- PublicServer是組內(nèi)跨服組隊和聊天,也就是在一個服務器名字下面的跨服.這里跨服是物理服.
2- 控制和數(shù)據(jù)中心的功能是提供數(shù)據(jù)推送和信息收集,以及服務器狀態(tài)控制.
他和userserver進行通信,是為了進行數(shù)據(jù)更新,信息收集和狀態(tài)控制,在2的說明里已經(jīng)提到了。
3- 這里面的所有db都不是單純的一個數(shù)據(jù)庫,而是一套稱為dbproxy或者dbagent的東西,它有邏輯處理能力。
但是,它不會向數(shù)據(jù)中心要數(shù)據(jù)。在我的設計里,數(shù)據(jù)中心是請求者,而非被請求者。所有數(shù)據(jù)更新的發(fā)起者都是數(shù)據(jù)中心,因為所有用戶信息的修改都在這里進行。AreaDB只是被動的接受數(shù)據(jù)中心的數(shù)據(jù)更新,而不向數(shù)據(jù)中心要數(shù)據(jù)。 回復 更多評論
2- 控制和數(shù)據(jù)中心的功能是提供數(shù)據(jù)推送和信息收集,以及服務器狀態(tài)控制.
他和userserver進行通信,是為了進行數(shù)據(jù)更新,信息收集和狀態(tài)控制,在2的說明里已經(jīng)提到了。
3- 這里面的所有db都不是單純的一個數(shù)據(jù)庫,而是一套稱為dbproxy或者dbagent的東西,它有邏輯處理能力。
但是,它不會向數(shù)據(jù)中心要數(shù)據(jù)。在我的設計里,數(shù)據(jù)中心是請求者,而非被請求者。所有數(shù)據(jù)更新的發(fā)起者都是數(shù)據(jù)中心,因為所有用戶信息的修改都在這里進行。AreaDB只是被動的接受數(shù)據(jù)中心的數(shù)據(jù)更新,而不向數(shù)據(jù)中心要數(shù)據(jù)。 回復 更多評論
@飯中淹
多謝樓主解答,不過還是有一些疑問,我說一下自己對這個架構(gòu)的理解。
從用戶登錄開始,用戶登錄連接網(wǎng)關(guān),發(fā)數(shù)據(jù)到loginserver校驗賬戶密碼,如果areaDB中沒有賬戶信息,向數(shù)據(jù)中心要賬戶密碼,插入areaDB,以后校驗賬戶就可以直接在區(qū)域DB中做了,如果賬戶密碼校驗成功,發(fā)送本區(qū)的組列表給客戶端,玩家選擇某個服務器,login獲取生成一個key發(fā)給userserver,同時把key發(fā)給客戶端以及一個網(wǎng)關(guān)的ip端口,客戶端使用其連接,發(fā)送key到Userserver,比對key,非法踢掉客戶端連接,合法userserver向數(shù)據(jù)中心獲取賬戶詳細信息,比如賬戶上剩余點卡等,同時向GroupDB獲取本組中的自己的角色,得到這些信息都發(fā)給客戶端,客戶端選擇一個角色進入游戲,userserver從數(shù)據(jù)庫讀取該角色的完全信息,根據(jù)玩家之前的位置確定進入那個gameserver(我認為游戲服務器是根據(jù)地圖劃分的,不知道對不對?),角色數(shù)據(jù)傳到gameserver,同時客戶端根據(jù)這些數(shù)據(jù)進入場景,gameserver得到信息同時告知publicserver(publicserver連DB做什么?我猜測可以獲取工會以及工會成員信息,對否?)
回復 更多評論
多謝樓主解答,不過還是有一些疑問,我說一下自己對這個架構(gòu)的理解。
從用戶登錄開始,用戶登錄連接網(wǎng)關(guān),發(fā)數(shù)據(jù)到loginserver校驗賬戶密碼,如果areaDB中沒有賬戶信息,向數(shù)據(jù)中心要賬戶密碼,插入areaDB,以后校驗賬戶就可以直接在區(qū)域DB中做了,如果賬戶密碼校驗成功,發(fā)送本區(qū)的組列表給客戶端,玩家選擇某個服務器,login獲取生成一個key發(fā)給userserver,同時把key發(fā)給客戶端以及一個網(wǎng)關(guān)的ip端口,客戶端使用其連接,發(fā)送key到Userserver,比對key,非法踢掉客戶端連接,合法userserver向數(shù)據(jù)中心獲取賬戶詳細信息,比如賬戶上剩余點卡等,同時向GroupDB獲取本組中的自己的角色,得到這些信息都發(fā)給客戶端,客戶端選擇一個角色進入游戲,userserver從數(shù)據(jù)庫讀取該角色的完全信息,根據(jù)玩家之前的位置確定進入那個gameserver(我認為游戲服務器是根據(jù)地圖劃分的,不知道對不對?),角色數(shù)據(jù)傳到gameserver,同時客戶端根據(jù)這些數(shù)據(jù)進入場景,gameserver得到信息同時告知publicserver(publicserver連DB做什么?我猜測可以獲取工會以及工會成員信息,對否?)
回復 更多評論
@飯中淹
明白,官網(wǎng)提供功能,玩家自己到官網(wǎng)激活,完成數(shù)據(jù)中心到區(qū)域數(shù)據(jù)的轉(zhuǎn)移。充值自己選區(qū),數(shù)據(jù)中心把數(shù)據(jù)更新到相應的areaDB中,這樣避免很多程序問題。
另外userserver和數(shù)據(jù)中心的數(shù)據(jù)交換是不是會是這個架構(gòu)的瓶頸?玩家登入登出都需要userserver和數(shù)據(jù)中心交換數(shù)據(jù),而數(shù)據(jù)中心一定是在外網(wǎng),而且所有區(qū)唯一,象網(wǎng)易同時在線上百萬,數(shù)據(jù)中心承受的壓力相當大,會很影響性能吧?盡管這個連接是短連接。 回復 更多評論
明白,官網(wǎng)提供功能,玩家自己到官網(wǎng)激活,完成數(shù)據(jù)中心到區(qū)域數(shù)據(jù)的轉(zhuǎn)移。充值自己選區(qū),數(shù)據(jù)中心把數(shù)據(jù)更新到相應的areaDB中,這樣避免很多程序問題。
另外userserver和數(shù)據(jù)中心的數(shù)據(jù)交換是不是會是這個架構(gòu)的瓶頸?玩家登入登出都需要userserver和數(shù)據(jù)中心交換數(shù)據(jù),而數(shù)據(jù)中心一定是在外網(wǎng),而且所有區(qū)唯一,象網(wǎng)易同時在線上百萬,數(shù)據(jù)中心承受的壓力相當大,會很影響性能吧?盡管這個連接是短連接。 回復 更多評論
@飯中淹
其實對Agent的作用還是很不解.首先從走路來說, pc--->發(fā)送走路到agent,agent--->將消息轉(zhuǎn)發(fā)到gameserver--->gameserver
感覺這時候有問題了.gameserver是不是要廣播到所有的agent?然后agent在通知所有的人? 還是在gameserver紀錄一個用戶的agent,先產(chǎn)生哪些用戶需要接收這個人的消息,然后再直接通知這些用戶所在的agent,agent再通知pc,pc實現(xiàn)行走?
另外,這樣是不是會加大網(wǎng)絡延時?這樣對技能的冷卻時間是不是有很高的要求? 回復 更多評論
其實對Agent的作用還是很不解.首先從走路來說, pc--->發(fā)送走路到agent,agent--->將消息轉(zhuǎn)發(fā)到gameserver--->gameserver
感覺這時候有問題了.gameserver是不是要廣播到所有的agent?然后agent在通知所有的人? 還是在gameserver紀錄一個用戶的agent,先產(chǎn)生哪些用戶需要接收這個人的消息,然后再直接通知這些用戶所在的agent,agent再通知pc,pc實現(xiàn)行走?
另外,這樣是不是會加大網(wǎng)絡延時?這樣對技能的冷卻時間是不是有很高的要求? 回復 更多評論
只有注冊用戶登錄后才能發(fā)表評論。 | ||
【推薦】100%開源!大型工業(yè)跨平臺軟件C++源碼提供,建模,組態(tài)!
![]() |
||
網(wǎng)站導航:
博客園
IT新聞
BlogJava
博問
Chat2DB
管理
|
||
|