首先，二话不说，上图（用Windows画图画的。。。）
这个图是一个区的架构图，所有区的架构是一样的。上面虚线框的ServerGroup和旁边方框内的架构一样。图上的所有x N的服务器，都是多台一起的。红线，绿线，和蓝线图上也有图示，这里就不多介绍了。关于Agent Server大家也能看出来，其实就是Gate。
这里主要介绍下图上的标记了号码的位置的数据连接的内容和意义。
1- 这是一条WebService的管道，在用户激活该区帐号，或者修改帐号密码的时候，通过这条通道来插入和更新用户的帐号信息。
2- 这也是一条WebService管道，用来获取和控制用户该该组内的角色信息，以及进行付费商城代币之类的更新操作。
3- 这是一条本地的TCP/IP连接，这条连接主要用来进行服务器组在登陆服务器的注册，以及登陆服务器验证帐户后，向用户服务器注册帐户登陆信息，以及进行对已经登陆的帐户角色信息进行操作（比如踢掉当前登陆的角色），还有服务器组的信息更新（当前在线玩家数量等）。
4- 这也是一条本地TCP/IP连接，这条连接用来对连接到GameServer的客户端进行验证，以及获取角色数据信息，还有传回GameServer上角色的数据信息改变。
5- 这条连接也是一条本地的TCP/IP连接，它用来进行公共信息服务器和数个游戏服务器间的交互，用来交换一些游戏世界级的信息（比如公会信息，跨服组队信息，跨服聊天频道等）。
6- 这里的两条连接，想表达的意思是，UserServer和GameServer的Agent是可以互换使用的，也就是玩家进入组内之后，就不需要再切换Agent。如果不怕乱套，也可以把登陆服务器的Agent也算上，这样用户整个过程里就不需要再更换Agent，减少重复连接的次数，也提高了稳定性。（毕竟连接次数少了，也降低了连不上服务器的出现几率）
在这个架构里面，GameServer实际上是一个游戏逻辑的综合体，里面可以再去扩展成几个不同的逻辑服务器，通过PublicServer进行公共数据交换。
UserServer实际上扮演了一个ServerGroup的领头羊的角色，它负责向LoginServer注册和更新服务器组的信息（名字，当前人数），并且对Agent进行调度，对选择了该组的玩家提供一个用户量最少的Agent。同时，它也兼了一个角色管理服务器的功能，发送给客户端当前的角色列表，角色的创建，删除，选择等管理操作，都是在这里进行的。而且，它还是一个用户信息的验证服务器，GameServer需要通过它来进行客户端的合法性验证，以及获取玩家选择的角色数据信息。
采用这种架构的游戏，通常有以下表现。
1- 用户必须激活一个大区，才能在大区内登陆自己的帐号。
2- 用户启动客户端的时候，弹出一个登陆器，选择大区。
3- 用户启动真正的客户端的时候，一开始就是输入帐号密码。
4- 帐号验证完成之后，进行区内的服务器选择。
5- 服务器选择完成之后，进入角色管理。同时，角色在不同的服务器里不能共享。
市面上符合上面几个表现特征的游戏相当的多，而且也不乏旷世巨作。这个架构不是一个新的架构，但是它足够经典和完善，并且逻辑简单而清晰，用来做MMORPG，或者其它网络游戏的服务器架构，是一种不错的选择。
# re: 一种经典的网络游戏服务器架构 2008-04-16 09:43 alittlewolf
有几个问题:
(1) Public Server是否会成为瓶颈呢?
(2) User Server压力会不会过大?
(3) Login Server是不是也要考虑分布式?
(4) Group DB是通过何种方式保证性能? 分布式数据库? 引入高价的存储设备?
# re: 一种经典的网络游戏服务器架构 2008-04-16 09:46 alittlewolf
另外一个不解的地方是, 为什么所有Server前面都放着Agent Server? 从安全性方面考虑? 告别Game Server Group前面的Agent Server Group, 望解释.
# re: 一种经典的网络游戏服务器架构 2008-04-16 09:47 alittlewolf
另外一个不解的地方是, 为什么所有Server前面都放着Agent Server? 从安全性方面考虑? 特别是Game Server Group前面的Agent Server Group, 望解释.
@alittlewolf
(1) 每组承载量，一般是10000人左右。在目前主流服务器硬件条件下，PublicServer为这些人做服务是轻松的。
(2) UserServer 没有太大压力，只是做为一个验证平台，角色管理的资源消耗也不大，这个在实际中已经验证过了。
(3) LoginServer 没什么必要分布式，虽然一般登陆的压力比较大，但是对于一个组来说，登陆验证都是消耗最小的一个操作，没有长期压力。而且它的硬件条件也是比较好的，所以不用分布式的，那样会增加整个系统的复杂性。
(4) 一般这种架构下，GroupDB和UserServer之间会做一个Cache，杜绝频繁的数据库读写。处于安全性和性能考虑，可以选择带有集群功能的数据库。不过从成本出发，一般是单台的DB服务器，一个库搞定。
(5) Agent是用来进行用户过滤，分流和调度的。同时也是出于安全性考虑。另外也是为了降低后台服务器的压力。而且用Agent可以实现很多比较效率的处理方式。
目前主流的mmo应该都是这种架构，足够用了。关键点在一个agent，
安全性，负载均衡， 后台服务的屏蔽，都有保障了。
# re: 一种经典的网络游戏服务器架构 2008-08-13 11:43 非风
一些疑问，希望得到博主的解答：
PublicServer要完成跨服组队信息，跨服聊天频道功能，那么它不应该放置在方框中，不能属于特定的组中，因为它还需要和其他组交换数据。
ControlAndDataCenter的功能是什么?是不是它仅仅就是一个DB 中心，全国所有区域服务器的一个数据中心，区域服务器从它拿玩家的帐号信息？
如果是UserServer为什么要连接它,前面在激活时候所有数据已经获取到了AreaDB中？
AreaDB仅仅是一个DB它如何通过○1 向ControlAndDataCenter要数据？
1- PublicServer是组内跨服组队和聊天,也就是在一个服务器名字下面的跨服.这里跨服是物理服.
2- 控制和数据中心的功能是提供数据推送和信息收集,以及服务器状态控制.
他和userserver进行通信，是为了进行数据更新，信息收集和状态控制，在2的说明里已经提到了。
3- 这里面的所有db都不是单纯的一个数据库，而是一套称为dbproxy或者dbagent的东西，它有逻辑处理能力。
但是，它不会向数据中心要数据。在我的设计里，数据中心是请求者，而非被请求者。所有数据更新的发起者都是数据中心，因为所有用户信息的修改都在这里进行。AreaDB只是被动的接受数据中心的数据更新，而不向数据中心要数据。
# re: 一种经典的网络游戏服务器架构 2008-08-15 14:53 非风
@饭中淹
多谢楼主解答，不过还是有一些疑问，我说一下自己对这个架构的理解。
从用户登录开始，用户登录连接网关，发数据到loginserver校验账户密码，如果areaDB中没有账户信息，向数据中心要账户密码，插入areaDB，以后校验账户就可以直接在区域DB中做了，如果账户密码校验成功，发送本区的组列表给客户端，玩家选择某个服务器，login获取生成一个key发给userserver，同时把key发给客户端以及一个网关的ip端口，客户端使用其连接，发送key到Userserver，比对key，非法踢掉客户端连接，合法userserver向数据中心获取账户详细信息，比如账户上剩余点卡等，同时向GroupDB获取本组中的自己的角色，得到这些信息都发给客户端，客户端选择一个角色进入游戏，userserver从数据库读取该角色的完全信息，根据玩家之前的位置确定进入那个gameserver（我认为游戏服务器是根据地图划分的，不知道对不对？），角色数据传到gameserver，同时客户端根据这些数据进入场景，gameserver得到信息同时告知publicserver（publicserver连DB做什么？我猜测可以获取工会以及工会成员信息，对否？）
@非风
是的,差不多的.
不过我不会让AreaDB去数据中心请求数据。
我在上面说的是，只有用户进行激活，才会把用户资料放到AreaDB
而且点卡都是按照Area来冲值的。
所有的游戏需要的资料都在Area本地提供，不会向数据中心请求数据。
# re: 一种经典的网络游戏服务器架构 2008-08-15 18:13 非风
@饭中淹
明白，官网提供功能，玩家自己到官网激活，完成数据中心到区域数据的转移。充值自己选区，数据中心把数据更新到相应的areaDB中，这样避免很多程序问题。
另外userserver和数据中心的数据交换是不是会是这个架构的瓶颈？玩家登入登出都需要userserver和数据中心交换数据，而数据中心一定是在外网，而且所有区唯一，象网易同时在线上百万，数据中心承受的压力相当大，会很影响性能吧？尽管这个连接是短连接
@非风
玩家登入登出，userserver不需要和数据中心交换数据.
数据中心只是查询和收集服务器信息或者个人信息的时候才需要和userserver进行交互。
玩家的角色信息都是保存在GroupDB里面的。