关于MMORPG服务器的一些想法
时间：2010-11-14 来源：bellcat2008
根据网上各位达人的思想归纳而得，纯属转载，便于自己消化理解，纯属涂鸦。
文献列表：
游戏设计：服务器结构探讨-登录服的负载均衡
http://edu.gamfe.com/d/7789.html
无缝世界网游服务器架构的设计思路
http://blog.csdn.net/romandion/archive/2009/04/02/4044368.aspx
1.登录服务器
登录服在设计上应该能满足动态增删的需求，我们可以在任何时候为大区增加或减少登录服的部署。例如：也许我们的一个拥有20个游戏世界的大区仅仅使用10台或更少的登录服即可满足需求。而当在开新区的时候，或许要配备40台登录服才能应付那如潮水般涌入的玩家登录请求。添加太多的登录服务器，但游戏世界服务器承载能力依然有限，玩家依然要排队等待或进入游戏卡。
将玩家提交的帐号和密码送到数据库进行验证，和生成会话密钥发送给游戏服和客户端，操作完成后连接就会立即断开，而且玩家在以后的游戏过程中不会再与登录服打任何交道。
问题1？增加登录服务器，客户端如何知晓新的LoginServer？
可以采用dns负载均衡，通过在DNS中为一个域名配置多个IP地址来实现。最新的DNS服务已实现了根据服务器系统状态来实现的动态负载均衡，也就是实现了真正意义上的负载均衡，这样也就有效地解决了当某台登录服当机后，DNS服务器不能立即做出反应的问题。
大区服务器
/ | \ \
/ | \ \
登录服1 登录服2 世界服1 世界服2
\ | | |
\ | | |
帐号数据库 DBS DBS
一般来说，在各个大区帐号数据库之上还有一个总的帐号数据库，我们可以称它为中心数据库。比如我们在官网上注册了一个帐号，这时帐号数据是只保存在中心数 据库上的。而当我们要到一区去创建角色开始游戏的时候，在一区的帐号数据库中并没有我们的帐号数据，所以，我们必须先到官网上做一次激活操作。这个激活的 过程也就是从中心库上把我们的帐号数据拷贝到所要到的大区帐号数据库中。
2.无缝世界网游服务器架构：
Services-based Architecture——基于服务的架构。在这种架构内部，我们根据处理 数据、逻辑的相关性来划分组内各个服务器的工作任务。例如：位置服务提供物体可见性信息、物品服务处理所有物品相关的逻辑、社会关系服务提供行会家族等等 方面的逻辑、战斗服务器只处理战斗相关的逻辑，等等。这样划分的话、逻辑处理的并发就有了可能性。举例来说：A砍B一刀这件事情与C从奸商手里买到一件武 器这个事情是完全不相干的，而且这2个请求本来就在不同的服务器上被处理，他们是被不同的Service Server并发处理的。这就是 Services-based Architecture 的并发方法。基本上，把游戏逻辑的处理拆分成一个个的service，就和设计cpu的时候把机器指令的具体处理拆分，然后设计出一个个流水线单元是一个道理。
Cells-based Architecture——基于cell的架构。每个cell都在不同的物理 server上面运行着完全一样的应用程序服务器，但是他们负责承载不同的游戏场景区域的游戏逻辑。和 services-based arch. 明显不同的就是，每个cell都是个‘在逻辑上完整的’服务器。它得处理物品操作、人物移动、战斗计算等等几乎所有的游戏逻辑。尽管这么做会带来一些（可 能是很复杂）的问题，但是它完全是可行的。举例来说：在吴国A砍B一刀显然地和千里之外在越国的C砍D一刀不搭界，他们完全可以被不同的Cell并发地处 理。
基本上，这就相当于一个主板上面插多个CPU或者一个CPU但是有多个内核，每个CPU能做的事情都是一样的，而且能一起做。
3.游戏世界服务器架构
我们来看看结构图是怎样的：
中心服务器
/ \ \
/ \ \
登录服 地图1 地图2 地图n
\ | / /
\ | / /
客户端
文献列表：
游戏设计：服务器结构探讨-登录服的负载均衡
http://edu.gamfe.com/d/7789.html
无缝世界网游服务器架构的设计思路
http://blog.csdn.net/romandion/archive/2009/04/02/4044368.aspx
1.登录服务器
登录服在设计上应该能满足动态增删的需求，我们可以在任何时候为大区增加或减少登录服的部署。例如：也许我们的一个拥有20个游戏世界的大区仅仅使用10台或更少的登录服即可满足需求。而当在开新区的时候，或许要配备40台登录服才能应付那如潮水般涌入的玩家登录请求。添加太多的登录服务器，但游戏世界服务器承载能力依然有限，玩家依然要排队等待或进入游戏卡。
将玩家提交的帐号和密码送到数据库进行验证，和生成会话密钥发送给游戏服和客户端，操作完成后连接就会立即断开，而且玩家在以后的游戏过程中不会再与登录服打任何交道。
问题1？增加登录服务器，客户端如何知晓新的LoginServer？
可以采用dns负载均衡，通过在DNS中为一个域名配置多个IP地址来实现。最新的DNS服务已实现了根据服务器系统状态来实现的动态负载均衡，也就是实现了真正意义上的负载均衡，这样也就有效地解决了当某台登录服当机后，DNS服务器不能立即做出反应的问题。
大区服务器
/ | \ \
/ | \ \
登录服1 登录服2 世界服1 世界服2
\ | | |
\ | | |
帐号数据库 DBS DBS
一般来说，在各个大区帐号数据库之上还有一个总的帐号数据库，我们可以称它为中心数据库。比如我们在官网上注册了一个帐号，这时帐号数据是只保存在中心数 据库上的。而当我们要到一区去创建角色开始游戏的时候，在一区的帐号数据库中并没有我们的帐号数据，所以，我们必须先到官网上做一次激活操作。这个激活的 过程也就是从中心库上把我们的帐号数据拷贝到所要到的大区帐号数据库中。
2.无缝世界网游服务器架构：
Services-based Architecture——基于服务的架构。在这种架构内部，我们根据处理 数据、逻辑的相关性来划分组内各个服务器的工作任务。例如：位置服务提供物体可见性信息、物品服务处理所有物品相关的逻辑、社会关系服务提供行会家族等等 方面的逻辑、战斗服务器只处理战斗相关的逻辑，等等。这样划分的话、逻辑处理的并发就有了可能性。举例来说：A砍B一刀这件事情与C从奸商手里买到一件武 器这个事情是完全不相干的，而且这2个请求本来就在不同的服务器上被处理，他们是被不同的Service Server并发处理的。这就是 Services-based Architecture 的并发方法。基本上，把游戏逻辑的处理拆分成一个个的service，就和设计cpu的时候把机器指令的具体处理拆分，然后设计出一个个流水线单元是一个道理。
Cells-based Architecture——基于cell的架构。每个cell都在不同的物理 server上面运行着完全一样的应用程序服务器，但是他们负责承载不同的游戏场景区域的游戏逻辑。和 services-based arch. 明显不同的就是，每个cell都是个‘在逻辑上完整的’服务器。它得处理物品操作、人物移动、战斗计算等等几乎所有的游戏逻辑。尽管这么做会带来一些（可 能是很复杂）的问题，但是它完全是可行的。举例来说：在吴国A砍B一刀显然地和千里之外在越国的C砍D一刀不搭界，他们完全可以被不同的Cell并发地处 理。
基本上，这就相当于一个主板上面插多个CPU或者一个CPU但是有多个内核，每个CPU能做的事情都是一样的，而且能一起做。
3.游戏世界服务器架构
我们来看看结构图是怎样的：
中心服务器
/ \ \
/ \ \
登录服 地图1 地图2 地图n
\ | / /
\ | / /
客户端
相关阅读 更多 +
