Webgame服务端分布式架构设计

Webgame服务端分布式架构设计

——By  King

          最近在设计实现Webgame服务端游戏架构，跟大家分享下。

以下对架构的几点说明：

1．  DB：数据库层。使用MongoDB, 可以作分布式，按webgame的需求，基本应该是不需要的。设置3个数据库，分别是GameData(游戏数据)， GameLog(游戏日志)，GameConfig(游戏配置)。

2．  Cache：缓存层。使用Redis，作为数据中间层。主从库分布，有了DB作永久存储，就不需要存储文件了。

3． SceneServer：逻辑服务器。负责场景业务逻辑。这层设计为分布式，有N个Server，每个Server可以管理多个场景。可以扩展为分线分布式。

4．  ProxyServer：代理服。处理玩家连接，和数据转发（到Server层），数据包加解密，和过滤非法数据包。这层设计为分布式，有N个 Proxy服，为了分压客户端连接。

        玩家在切换地图时，无需断开连接，只要更新该玩家在Proxy代理层的数据流向。

        为免减少复杂性，这里不设置World服或者Chat服，对于世界性的业务，可以通过Redis来转发处理。

        聊天在Proxy层直接使用redis的发布订阅就可以实现，数据不需要上到Server层，减少Server层压力。但是玩家登录时需要Server通 知Proxy玩家一些状态。另外也可以设计为单独的聊天集群，每个服都连接到聊天群，和游戏逻辑分离，好处是即使聊天挂掉，也不会影响游戏服。

       操作数据的原则：是先操作DB，再操作Cache，以数据库为准，确保数据无误。数据更改尽量作增量操作，而不是覆盖操作，减少并发产生的问题。

优点：

1.      分布式架构，可以通过增加服务器来分担逻辑服或代理服的压力。

2.      当一个代理服宕机后，也不会影响其它代理服的游戏。

3.      当一个场景服宕机后，影响的也只是当前地图的玩家。

4.      业务分离成单独的服务器，分散访问流量，而且可以动态增加，提高在线。

5.      代理保证了游戏服安全，使外网无法直接访问内网游戏服。

缺点: 

1.      代理服务器成为高负载情况下的通讯瓶颈问题

2.      Cache缓存在高负载下可能压力较大。

3.      由于网关的单节点故障导致整组服务器无法对外提供服务的问题

欢迎大家讨论和建议，转载请注明作者。——By  King

Email: [email protected]